From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes |
Date: | 2018-09-01 00:21:01 |
Message-ID: | 20180901002101.ph6cngswhqfmpaeh@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-09-01 00:33:03 | Re: pg_verify_checksums and -fno-strict-aliasing |
Previous Message | Tom Lane | 2018-08-31 23:59:58 | Re: pg_verify_checksums and -fno-strict-aliasing |