From: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update |
Date: | 2012-11-27 11:09:58 |
Message-ID: | CABOikdMzH50WoOH_E1U+u2X+Rsiz18Q5stODRDEdCxycGJCcSQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 27, 2012 at 4:22 PM, Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-11-27 11:18:06 | Re: Bugs in CREATE/DROP INDEX CONCURRENTLY |
Previous Message | Andres Freund | 2012-11-27 10:55:59 | Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update |