Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes
От | Tom Lane |
---|---|
Тема | Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes |
Дата | |
Msg-id | 14904.1535759623@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > Leaving that aside, I think there's one architectural aspect of my > approach that I prefer over yours: Deduplicating eager cache rebuilds > like my approach does seems quite advantageous. That is attractive, for sure, but the other side of the coin is that getting there seems to require a lot of ticklish redesign. We would certainly not consider back-patching such a change normally, and I'm unconvinced that we should do so in this case. My thought is to do (and back-patch) my change, and then work on yours as a performance improvement for HEAD only. 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.) regards, tom lane
В списке pgsql-hackers по дате отправления: