From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Bugs in CREATE/DROP INDEX CONCURRENTLY |
Date: | 2012-11-27 22:13:25 |
Message-ID: | 20121127221324.GB18093@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2012-11-27 16:31:15 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2012-11-27 22:24:05 | Re: MySQL search query is not executing in Postgres DB |
Previous Message | Peter Eisentraut | 2012-11-27 22:09:15 | Re: MySQL search query is not executing in Postgres DB |