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
