Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update
Date
Msg-id CABOikdMzH50WoOH_E1U+u2X+Rsiz18Q5stODRDEdCxycGJCcSQ@mail.gmail.com
Whole thread Raw
In response to Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers



On Tue, Nov 27, 2012 at 4:22 PM, Andres Freund <andres@2ndquadrant.com> wrote:
On 2012-11-27 11:48:08 +0100, Andres Freund wrote:

>
> I haven't yet looked deeply enough to judge whether there are actually
> bugs. But I can say that the e.g. the missing indisvalid checks in
> transformFkeyCheckAttrs makes me pretty uneasy. Vacuum not checking
> whether indexes are ready isn't nice either.

At least the former was easy enough to verify after thinking about it
for a minute (<=9.1):

CREATE TABLE clusterbug(id serial primary key, data int);
INSERT INTO clusterbug(data) VALUES(2),(2);
CREATE UNIQUE INDEX CONCURRENTLY clusterbug_data ON clusterbug(data);
CREATE TABLE clusterbug_ref(id serial primary key, clusterbug_id int references clusterbug(data));

Now a !indisready index is getting queried (strangely enough that
doesn't cause an error).


There might be a bug there as you are suggesting, but for me the CREATE INDEX itself fails (and rightly so) because of duplicate keys. Do I need to run these statements in different sessions ?

Thanks,
Pavan

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update
Next
From: Andres Freund
Date:
Subject: Re: Bugs in CREATE/DROP INDEX CONCURRENTLY