From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Euler Taveira <euler(dot)taveira(at)2ndquadrant(dot)com> |
Cc: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: More tests with USING INDEX replident and dropped indexes |
Date: | 2020-08-17 06:59:25 |
Message-ID: | 20200817065925.GD7787@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
logidec-index-v2.patch | text/x-diff | 25.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-08-17 07:00:17 | Re: Commit/abort WAL records with dropped rels missing XLR_SPECIAL_REL_UPDATE |
Previous Message | Pavel Stehule | 2020-08-17 06:46:39 | proposal - reference to plpgsql_check from plpgsql doc |