Handle parallel index builds on mapped relations.
authorPeter Geoghegan <pg@bowt.ie>
Fri, 10 Aug 2018 20:01:34 +0000 (13:01 -0700)
committerPeter Geoghegan <pg@bowt.ie>
Fri, 10 Aug 2018 20:01:34 +0000 (13:01 -0700)
commit4974d7f87e62a58e80c6524e49677cb25cc10e12
treedff7c5c0c15c4e407aa0187047cf0dc922460656
parentd4a900458e505092a8013eb77c9631d58c3c2a0a
Handle parallel index builds on mapped relations.

Commit 9da0cc35284, which introduced parallel CREATE INDEX, failed to
propagate relmapper.c backend local cache state to parallel worker
processes.  This could result in parallel index builds against mapped
catalog relations where the leader process (participating as a worker)
scans the new, pristine relfilenode, while worker processes scan the
obsolescent relfilenode.  When this happened, the final index structure
was typically not consistent with the owning table's structure.  The
final index structure could contain entries formed from both heap
relfilenodes.  Only rebuilds on mapped catalog relations that occur as
part of a VACUUM FULL or CLUSTER could become corrupt in practice, since
their mapped relation relfilenode swap is what allows the inconsistency
to arise.

On master, fix the problem by propagating the required relmapper.c
backend state as part of standard parallel initialization (Cf. commit
29d58fd3).  On v11, simply disallow builds against mapped catalog
relations by deeming them parallel unsafe.

Author: Peter Geoghegan
Reported-By: "death lock"
Reviewed-By: Tom Lane, Amit Kapila
Bug: #15309
Discussion: https://postgr.es/m/153329671686.1405.18298309097348420351@wrigleys.postgresql.org
Backpatch: 11-, where parallel CREATE INDEX was introduced.
src/backend/access/transam/README.parallel
src/backend/access/transam/parallel.c
src/backend/access/transam/xact.c
src/backend/utils/cache/relmapper.c
src/include/utils/relmapper.h