Re: Add support for ALTER INDEX .. ALTER [COLUMN] col_num {SET,RESET}

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

In response to

Browse pgsql-hackers by date

  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