Re: BUG #15309: ERROR: catalog is missing 1 attribute(s) for relid 760676 when max_parallel_maintenance_workers > 0
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #15309: ERROR: catalog is missing 1 attribute(s) for relid 760676 when max_parallel_maintenance_workers > 0 |
| Дата | |
| Msg-id | 13228.1533590989@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: BUG #15309: ERROR: catalog is missing 1 attribute(s) for relid760676 when max_parallel_maintenance_workers > 0 (Peter Geoghegan <pg@bowt.ie>) |
| Ответы |
Re: BUG #15309: ERROR: catalog is missing 1 attribute(s) for relid760676 when max_parallel_maintenance_workers > 0
|
| Список | pgsql-bugs |
Peter Geoghegan <pg@bowt.ie> writes:
> 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.
Hm. Post-beta3, I think I'd vote for a conservative fix in v11,
which seems to be "ban for mapped catalogs". Feel free to make
it work in HEAD, though.
regards, tom lane
В списке pgsql-bugs по дате отправления: