From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Peter Geoghegan <pg@bowt.ie>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: buildfarm: could not read block 3 in file "base/16384/2662": read
 only 0 of 8192 bytes
In-reply-to: <20180831221331.3l22nwxrokqeujav@alap3.anarazel.de>
References: <fcab55ec-660a-bc43-7fe1-09af3665e89a@2ndquadrant.com>
 <20180811140823.gyxqbtjbr5uitgsf@alap3.anarazel.de>
 <20180828075213.yqyl3w2gpd5heopd@alap3.anarazel.de>
 <20180829025658.brk3hfdczo3f73al@alap3.anarazel.de>
 <6970.1535512705@sss.pgh.pa.us>
 <20180829032714.6yu3bxdywcvyj2li@alap3.anarazel.de>
 <20180829032908.o46wdjmti6c6dfep@alap3.anarazel.de>
 <20180829083730.n645apqhb2gyih3g@alap3.anarazel.de>
 <17825.1535556627@sss.pgh.pa.us> <25024.1535579899@sss.pgh.pa.us>
 <20180831221331.3l22nwxrokqeujav@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Fri, 31 Aug 2018 15:13:31 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14903.1535759623.1@sss.pgh.pa.us>
Date: Fri, 31 Aug 2018 19:53:43 -0400
Message-ID: <14904.1535759623@sss.pgh.pa.us>
Precedence: bulk

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