Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6
Date
Msg-id 5483.1556737736@sss.pgh.pa.us
Whole thread Raw
In response to Re: REINDEX INDEX results in a crash for an index of pg_class since9.6  (Andres Freund <andres@anarazel.de>)
Responses Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2019-05-01 10:06:03 -0700, Andres Freund wrote:
>> I'm not sure this is the right short-term answer. Why isn't it, for now,
>> sufficient to do what I suggested with RelationSetNewRelfilenode() not
>> doing the CommandCounterIncrement(), and reindex_index() then doing the
>> SetReindexProcessing() before a CommandCounterIncrement()? That's like
>> ~10 line code change, and a few more with comments.

That looks like a hack to me...

The main thing I'm worried about right now is that I realized that
our recovery from errors in this area is completely hosed, cf
https://www.postgresql.org/message-id/4541.1556736252@sss.pgh.pa.us

The problem with CCA is actually kind of convenient for testing that,
since it means you don't have to inject any new fault to get an error
to be thrown while the index relcache entry is in the needing-to-be-
reverted state.  So I'm going to work on fixing the recovery first.
But I suspect that doing this right will require the more complicated
approach anyway.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Commits 8de72b and 5457a1 (COPY FREEZE)
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Commits 8de72b and 5457a1 (COPY FREEZE)