Re: Bugs in CREATE/DROP INDEX CONCURRENTLY

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bugs in CREATE/DROP INDEX CONCURRENTLY
Date: 2012-11-28 23:41:39
Message-ID: 19610.1354146099@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-11-28 23:49:52 Re: [HACKERS] pgsql: Refactor flex and bison make rules
Previous Message Andrew Dunstan 2012-11-28 23:29:56 Re: [HACKERS] pgsql: Refactor flex and bison make rules