| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, deathlock13(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #15309: ERROR: catalog is missing 1 attribute(s) for relid 760676 when max_parallel_maintenance_workers > 0 |
| Date: | 2018-08-06 22:14:39 |
| Message-ID: | 14965.1533593679@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2018-Aug-06, Peter Geoghegan wrote:
>> Sure enough, that's what the bug is - a few debugging calls to
>> RelationMapFilenodeToOid() within nbtsort.c proves it.
> Uh, that's weird, isn't it? I mean, why is the relfilenode changing
> underneath?
Because we're building a brand new index in a new file.
> Why isn't it blocked by the CREATE INDEX? Or is CREATE
> INDEX inflicting that upon itself?
The problem is (or so I assume) failure to propagate process-local
state of relmapper.c into the worker processes. So the leader knows
that we've assigned a new relfilenode to some mapped index, but the
workers don't.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2018-08-06 22:16:49 | Re: BUG #15309: ERROR: catalog is missing 1 attribute(s) for relid 760676 when max_parallel_maintenance_workers > 0 |
| Previous Message | Alvaro Herrera | 2018-08-06 22:10:23 | Re: BUG #15309: ERROR: catalog is missing 1 attribute(s) for relid 760676 when max_parallel_maintenance_workers > 0 |