From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
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-08-31 23:53:43 |
Message-ID: | 14904.1535759623@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-08-31 23:59:58 | Re: pg_verify_checksums and -fno-strict-aliasing |
Previous Message | Tomas Vondra | 2018-08-31 23:45:52 | Re: Some pgq table rewrite incompatibility with logical decoding? |