Restore relmapper state early enough in parallel workers.
authorTom Lane <[email protected]>
Fri, 20 Sep 2024 00:58:17 +0000 (20:58 -0400)
committerTom Lane <[email protected]>
Fri, 20 Sep 2024 00:58:21 +0000 (20:58 -0400)
commit126ec0bc76d044d3a9eb86538b61242bf7da6db4
treef4b2c5d33c3cadaecae5707b64a01bf9d434060b
parent91287b5f5da324ac24678f556962e1b95e52240c
Restore relmapper state early enough in parallel workers.

We need to do RestoreRelationMap before loading catalog-derived
state, else the worker may end up with catalog relcache entries
containing stale relfilenode data.  Move up RestoreReindexState
too, on the principle that that should also happen before we
do much of any catalog access.

I think ideally these things would happen even before InitPostgres,
but there are various problems standing in the way of that, notably
that the relmapper thinks "active" mappings should be discarded at
transaction end.  The implication of this is that InitPostgres and
RestoreLibraryState will see the same catalog state as an independent
backend would see, which is probably fine; at least, it's been like
that all along.

Per report from Justin Pryzby.  There is a case to be made that
this should be back-ed.  But given the lack of complaints
before 6e086fa2e and the short amount of time remaining before
17.0 wraps, I'll just put it in HEAD for now.

Discussion: https://postgr.es/m/ZuoU_8EbSTE14o1U@pryzbyj2023
src/backend/access/transam/parallel.c