Re: Bugs in CREATE/DROP INDEX CONCURRENTLY

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2012-10-05 19:56:40 -0400, Tom Lane wrote:
>> I think this could possibly be fixed by using nontransactional
>> update-in-place when we're trying to change indisvalid and/or
>> indisready, but I've not really thought through the details.

> I couldn't really think of any realistic method to fix this other than
> update in place. I thought about it for a while and I think it should
> work, but I have to say it makes me slightly uneasy.

I looked through the code a bit, and I think we should be able to make
this work, but note there are also places that update indcheckxmin using
heap_update, and that's just as dangerous as changing the other two
flags via heap_update, if you don't have exclusive lock on the table.
This is going to need some careful thought, because we currently expect
that such an update will set the pg_index row's xmin to the current XID,
which is something an in-place update can *not* do. I think this is a
non-problem during construction of a new index, since the xmin ought to
be the current XID already anyway, but it's less clear what to do in
REINDEX. In the short term there may be no problem since REINDEX takes
exclusive lock on the parent table anyway (and hence could safely do
a transactional update) but if we ever want REINDEX CONCURRENTLY we'll
need a better answer.

regards, tom lane