Re: Bugs in CREATE/DROP INDEX CONCURRENTLY

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.

> It strikes me that the whole idea of reusing xmin when indexcheckxmin is
> set is overly clever and storing the xid itself would have be been
> better... Too late though.

Well, the reason for that is documented in README.HOT: if the XID were
in an ordinary column there'd be no nice way to get it frozen when it
gets too old. As-is, VACUUM takes care of that problem automatically.

regards, tom lane