Re: BUG #15309: ERROR: catalog is missing 1 attribute(s) for relid 760676 when max_parallel_maintenance_workers > 0
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: deathlock13@gmail.com, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2018-08-06T21:21:33Z
Lists: pgsql-bugs
On Mon, Aug 6, 2018 at 1:37 PM, Peter Geoghegan <pg@bowt.ie> wrote: > To be clear, I mean that the leader process's worker state has the > right relfilenode (the leader process always participates as a > worker), but all worker processes have the stale relfilenode. Sure enough, that's what the bug is - a few debugging calls to RelationMapFilenodeToOid() within nbtsort.c proves it. Several approaches to fixing the bug occur to me: * Ban parallel CREATE INDEX for all catalogs. This was how things were up until several weeks before the original patch was committed. * Ban parallel CREATE INDEX for mapped catalogs only. * Find a way to propagate the state necessary to have parallel workers agree with the leader on the correct relfilenode. We could probably propagate backend-local state like active_local_updates without too much difficulty, which looks like it would fix the problem. Note that we did something very similar with reindex-pending-indexes lists in commit 29d58fd3. That commit similarly involved propagating more backend-local state so that parallel index builds (or at least REINDEX) on catalogs could be enabled/work reliably. Maybe we should continue down the road of making parallel builds work on catalogs, on general principle. Thoughts? -- Peter Geoghegan
Commits
-
Handle parallel index builds on mapped relations.
- 4974d7f87e62 12.0 landed
- 9353d94a9b70 11.0 landed
-
Transfer state pertaining to pending REINDEX operations to workers.
- 29d58fd3adae 11.0 cited