On 2012-11-27 16:31:15 -0500, Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
