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-29T08:37:30Z
Lists: pgsql-hackers
Attachments
- relcache-rebuild.diff (text/x-diff) patch
On 2018-08-28 20:29:08 -0700, Andres Freund wrote: > 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. > > Now I need to look for power for my laptop and some for me ;) A bit of food, a coke and a talk later, here's a first draft *prototype* of how this could be solved. It's not OK to rebuild relcache entries in the middle of ReceiveSharedInvalidMessages() - a later entry in the invalidation queue might be relmapper invalidation, and thus immediately processing a relcache invalidation might attempt to scan a relation that does not exist anymore. Instead, receiving a relcache invalidation now just queues an entry onto a new "pending rebuilds" list, that is then processed in a second stage, after emptying the entire sinval queue. At that stage we're guaranteed that the relmapper is up2date. This might actually have performance benefits in some realistic scenarios - while RelationFlushRelation() marks the relcache entry invalid for each of the received entries, ProcessPendingRelcacheRebuilds() can skip rebuilding if the entry has since been rebuild. Obviously this is far from clean enough, but what do you think about the basic approach? It does, in my limited testing, indeed solve the "could not read block" issue. 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