Re: buildfarm: could not read block 3 in file "base/16384/2662":read only 0 of 8192 bytes
От | Andres Freund |
---|---|
Тема | Re: buildfarm: could not read block 3 in file "base/16384/2662":read only 0 of 8192 bytes |
Дата | |
Msg-id | 20180829083730.n645apqhb2gyih3g@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: buildfarm: could not read block 3 in file "base/16384/2662":read only 0 of 8192 bytes (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes
Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes |
Список | pgsql-hackers |
On 2018-08-28 20:29:08 -0700, Andres Freund wrote: > On 2018-08-28 20:27:14 -0700, Andres Freund wrote: > > Locally that triggers the problem within usually a few seconds. > > FWIW, it does so including versions as old as 9.2. > > Now I need to look for power for my laptop and some for me ;) A bit of food, a coke and a talk later, here's a first draft *prototype* of how this could be solved. It's not OK to rebuild relcache entries in the middle of ReceiveSharedInvalidMessages() - a later entry in the invalidation queue might be relmapper invalidation, and thus immediately processing a relcache invalidation might attempt to scan a relation that does not exist anymore. Instead, receiving a relcache invalidation now just queues an entry onto a new "pending rebuilds" list, that is then processed in a second stage, after emptying the entire sinval queue. At that stage we're guaranteed that the relmapper is up2date. This might actually have performance benefits in some realistic scenarios - while RelationFlushRelation() marks the relcache entry invalid for each of the received entries, ProcessPendingRelcacheRebuilds() can skip rebuilding if the entry has since been rebuild. Obviously this is far from clean enough, but what do you think about the basic approach? It does, in my limited testing, indeed solve the "could not read block" issue. Greetings, Andres Freund
Вложения
В списке pgsql-hackers по дате отправления: