Re: Bugs in CREATE/DROP INDEX CONCURRENTLY

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bugs in CREATE/DROP INDEX CONCURRENTLY
Date: 2012-11-27 03:44:49
Message-ID: 26175.1353987889@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karl O. Pinc 2012-11-27 03:48:02 Re: Suggestion for --truncate-tables to pg_restore
Previous Message Tom Lane 2012-11-27 03:31:50 Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update