Re: Bugs in CREATE/DROP INDEX CONCURRENTLY - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bugs in CREATE/DROP INDEX CONCURRENTLY
Date
Msg-id 19610.1354146099@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bugs in CREATE/DROP INDEX CONCURRENTLY  (Andres Freund <andres@anarazel.de>)
Responses Re: Bugs in CREATE/DROP INDEX CONCURRENTLY  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2012-11-28 17:42:18 -0500, Tom Lane wrote:
>> I agree it's a judgment call, though.  Anybody want to argue for the
>> other position?

> Hm. Seems odd to include indexes that are being dropped concurrently at
> that moment. But then, we can't really detect that situation and as you
> say its consistent with pg_dump...

[ thinks about that for a bit... ]  We could have that, for about the same
cost as the currently proposed patch: instead of defining the added flag
column as "index is live", define it as "drop in progress", and set it
immediately at the start of the DROP CONCURRENTLY sequence.  Then the
"dead" condition that RelationGetIndexList must check for is "drop in
progress and not indisvalid and not indisready".

However, this is more complicated and harder to understand.  So unless
somebody is really excited about being able to tell the difference
between create-in-progress and drop-in-progress, I'd rather leave the
patch as-is.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [COMMITTERS] pgsql: Refactor flex and bison make rules
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Refactor flex and bison make rules