Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-08-29T03:51:47Z
Lists: pgsql-hackers
On 2018-08-28 23:32:51 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2018-08-28 20:27:14 -0700, Andres Freund wrote: > >> Locally that triggers the problem within usually a few seconds. > > > FWIW, it does so including versions as old as 9.2. 9.0 as well, so it's definitely not some recently backpatched change. > Interesting. One thing I'd like to know is why this only started > showing up in the buildfarm a few weeks ago. Maybe that's just a > timing effect, but it seems odd. I suspect it's largely timing and invalidation traffic. It's been really hard to reproduce with core regression tests after all. If my theory is right - and I'm getting more and more certain - that we're trying to access a remapped relation during invalidation, before reading the relevant relmapper invalidation, that also makes sense: You need to be unlucky enough that there's a relmapper invalidation *after* an invalidation for a currently "open" relation (otherwise we'd not do inval processing). Most of the time we'll likely just be "too fast" to process all the invalidations (thereby not getting to the point that pg_class has been remapped later in the queue). I think it might just be related to some modifed tests changing when exactly autovacuum is triggered, which then in turn triggers the invalidation. Unfortunately the only "real" fix I can think of is to change the relcache invalidation logic to only ever mark entries as 'invalid', and not do any eager rebuilding of the entries. That might be a good idea reasons for performance anyway, but is quite scary to imagine doing in a minor release. Greetings, Andres Freund
Commits
-
Limit depth of forced recursion for CLOBBER_CACHE_RECURSIVELY.
- f112d4088c29 9.3.25 landed
- 35e39610a3f8 9.4.20 landed
- cc4e99546ede 9.5.15 landed
- 2ef5c12ad5b6 9.6.11 landed
- adfc156d356a 10.6 landed
- 90fd3bfd1707 11.0 landed
- f510412df351 12.0 landed
-
Fix longstanding recursion hazard in sinval message processing.
- 395f310b04c5 9.6.11 landed
- 9e6f4fbdd0cf 10.6 landed
- 2569ca0dc8a2 11.0 landed
- f868a8143a98 12.0 landed
- bf919387ecc6 9.4.20 landed
- 95e9f928ce5e 9.3.25 landed
- 66321ae61baf 9.5.15 landed
-
Fix bugs in vacuum of shared rels, by keeping their relcache entries current.
- a54e1f158779 11.0 cited