Re: More tests with USING INDEX replident and dropped indexes - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: More tests with USING INDEX replident and dropped indexes
Date
Msg-id 20200817065925.GD7787@paquier.xyz
Whole thread Raw
In response to Re: More tests with USING INDEX replident and dropped indexes  (Euler Taveira <euler.taveira@2ndquadrant.com>)
Responses Re: More tests with USING INDEX replident and dropped indexes  (Rahila Syed <rahila.syed@2ndquadrant.com>)
List pgsql-hackers
On Wed, Jun 03, 2020 at 12:08:56PM -0300, Euler Taveira wrote:
> Consistency is a good goal. Why don't we clear the relreplident from the
> relation while dropping the index? relation_mark_replica_identity() already
> does that but do other things too. Let's move the first code block from
> relation_mark_replica_identity to another function and call this new
> function
> while dropping the index.

I have looked at your suggestion, and finished with the attached.
There are a couple of things to be aware of:
- For DROP INDEX CONCURRENTLY, pg_class.relreplident of the parent
table is set in the last transaction doing the drop.  It would be
tempting to reset the flag in the same transaction as the one marking
the index as invalid, but there could be a point in reindexing the
invalid index whose drop has failed, and this adds more complexity to
the patch.
- relreplident is switched to REPLICA_IDENTITY_NOTHING, which is the
behavior we have now after an index is dropped, even if there is a
primary key.
- The CCI done even if ri_type is not updated in index_drop() may look
useless, but the CCI will happen in any case as switching the replica
identity of a table to NOTHING resets pg_index.indisreplident for an
index previously used.

Thoughts?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: proposal - reference to plpgsql_check from plpgsql doc
Next
From: Michael Paquier
Date:
Subject: Re: Commit/abort WAL records with dropped rels missing XLR_SPECIAL_REL_UPDATE