From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alexander Korotkov <akorotkov(at)postgresql(dot)org> |
Subject: | Re: Add support for ALTER INDEX .. ALTER [COLUMN] col_num {SET,RESET} |
Date: | 2021-11-02 03:42:12 |
Message-ID: | YYCzlIBpoO6UtGCC@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Oct 30, 2021 at 09:45:50AM +0900, Michael Paquier wrote:
> Another thing that could be done is to mark the index as invalid once
> its set of opclass parameters is updated. That would be simpler,
> while allowing users to fire a concurrent or non-concurrent rebuild at
> will after an ALTER INDEX.
For the note here, I have looked at this possibility. And things
become very tricky when it comes to indexes marked as either
indisclustered or indisreplident. REINDEX CONCURRENTLY has the
particularity to switch both parameters to false when swapping to the
new index because we don't need the new index anymore. Invalid
indexes can create with CREATE INDEX CONCURRENTLY (constraint failure
at creation for example), but they won't have any of those flags set.
So we assume now that indisinvalid is linked to both of them.
This makes the problem mentioned upthread trickier than it looks, as
we'd need to decide what to do after an ALTER INDEX that just switches
an index to be invalid if any of these are set for the existing
index.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Nancarrow | 2021-11-02 03:51:34 | Re: Skipping logical replication transactions on subscriber side |
Previous Message | Michael Paquier | 2021-11-02 03:33:32 | Re: removing global variable ThisTimeLineID |