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 | 20180901002101.ph6cngswhqfmpaeh@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes
|
Список | pgsql-hackers |
Hi, On 2018-08-31 19:53:43 -0400, Tom Lane wrote: > My thought is to do (and back-patch) my change, and then work on yours > as a performance improvement for HEAD only. That does make sense. > I don't believe that yours would make mine redundant, either --- they > are good complementary changes to make real sure we have no remaining > bugs of this ilk. (In particular, no matter how much de-duplication > we do, we'll still have scenarios with recursive cache flushes; so I'm > not quite convinced that your solution provides a 100% fix by itself.) Yea this is a fair concern. One concern I have with your approach is that it isn't particularly bullet-proof for cases where the rebuild is triggered by something that doesn't hold a conflicting lock. If there's an independent cause to reload - something that very commonly happens - we might not necessarily re-trigger the recursive reloads. That *should* be safe due such changes hopefully being "harmless", but it's a bit disconcerting nonetheless. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: