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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_verify_checksums and -fno-strict-aliasing
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pg_verify_checksums and -fno-strict-aliasing