Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6
Date: 2019-05-01 16:20:22
Message-ID: 25049.1556727622@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> I see the bug. Turns out we need to figure out another way to solve the
> assertion triggered by doing catalog updates within
> RelationSetNewRelfilenode() - we can't just move the
> SetReindexProcessing() before it. When CCA is enabled, the
> CommandCounterIncrement() near the tail of RelationSetNewRelfilenode()
> triggers a rebuild of the catalog entries - but without the
> SetReindexProcessing() those scans will try to use the index currently
> being rebuilt.

Yeah. I think what this demonstrates is that REINDEX INDEX has to have
RelationSetIndexList logic similar to what REINDEX TABLE has, to control
which indexes get updated when while we're rebuilding an index of
pg_class. In hindsight that seems glaringly obvious ... I wonder how we
missed that when we built that infrastructure for REINDEX TABLE?

I'm pretty sure that infrastructure is my fault, so I'll take a
whack at fixing this.

Did you figure out why this doesn't also happen in HEAD?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-05-01 16:34:04 Re: pgsql: Compute XID horizon for page level index vacuum on primary.
Previous Message Andres Freund 2019-05-01 16:20:21 Re: using index or check in ALTER TABLE SET NOT NULL