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-08-29T20:41:42Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2018-08-29 14:00:12 -0400, Tom Lane wrote:
>> 2. I think we may need to address the same order-of-operations hazards
>> as RelationCacheInvalidate() worries about.  Alternatively, maybe we
>> could simplify that function by making it use the same
>> delayed-revalidation logic as we're going to develop for this.

> Hm, just to make sure I understand correctly: You're thinking about
> having to rebuild various nailed entries in a specific order [2]?

> [2] Hm, I'm right now a bit confused as to why "Other nailed relations
> go to the front of rebuildList" is a good idea.

I'm not recalling the reason right now either, but I'm pretty sure that
logic was added out of necessity ... it hasn't always been like that.

			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.