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