Re: Bugs in CREATE/DROP INDEX CONCURRENTLY - Mailing list pgsql-hackers

On 2012-11-27 16:31:15 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2012-11-27 14:41:34 -0500, Tom Lane wrote:
> >> The stuff you are allowed to ALTER is pretty much
> >> irrelevant to the index's life as an index.
>
> > Isn't inisprimary updated when an ALTER TABLE ... ADD PRIMARY KEY
> > ... USING someindex ; is done? Also I think indoption might be written
> > to as well.
>
> Ugh, you're right.  Somebody wasn't paying attention when those ALTER
> commands were added.
>
> We could probably alleviate the consequences of this by having those
> operations reset indcheckxmin if the tuple's old xmin is below the
> GlobalXmin horizon.  That's something for later though --- it's not
> a data corruption issue, it just means that the index might unexpectedly
> not be used for queries for a little bit after an ALTER.

mark_index_clustered() does the same btw, its not a problem in the
CLUSTER ... USING ...; case because that creates a new pg_index entry
anyway but in the ALTER TABLE one thats not the case.

Greetings,

Andres Freund

--Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services