Horton

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>

View thread View on postgr.es
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>
Date: 2018-09-01T14:54:25Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> 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.

Wouldn't that be a bug in the something-else?  The entire relation cache
system is based on the assumptions that (a) if you hold lock, you can read
a consistent and valid set of information about the rel from the catalogs,
and (b) anyone changing that info must hold a conflicting lock and send an
SINVAL message *before* releasing said lock.  I'm not prepared to consider
a redesign of those assumptions, especially not for back-patching.

			regards, tom lane

Commits

  1. Limit depth of forced recursion for CLOBBER_CACHE_RECURSIVELY.

  2. Fix longstanding recursion hazard in sinval message processing.

  3. Fix bugs in vacuum of shared rels, by keeping their relcache entries current.