On 2018-08-28 23:32:51 -0400, Tom Lane wrote: > Andres Freund <and...@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