On 2012-11-27 11:52:11 +0100, Andres Freund wrote: > On 2012-11-27 11:48:08 +0100, Andres Freund wrote: > > On 2012-11-27 10:18:37 +0530, Pavan Deolasee wrote: > > > On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > > > > I wrote: > > > > > > > > Either state of indcheckxmin is valid with all three of these > > > > combinations, so the specific kluge I was contemplating above doesn't > > > > work. But there is no valid reason for an index to be in this state: > > > > > > > > indisvalid = true, indisready = false > > > > > > > > I suggest that to fix this for 9.2, we could abuse these flags by > > > > defining that combination as meaning "ignore this index completely", > > > > and having DROP INDEX CONCURRENTLY set this state during its final > > > > wait before removing the index. > > > > > > > > > > > Yeah, this looks much better, given our inability to add a new catalog > > > column in 9.2. Can we cheat a little though and use a value other than 0 > > > and 1 for indisvalid or indisready to tell the server to interpret it > > > differently ? I would assume not, but can't see a reason unless these > > > values are converted to other types and back to boolean. > > > > > > Andres complained about the fact that many callers of RelationGetIndexList > > > are probably not ready to process invalid or not-yet-ready indexes and > > > suggested that those changes should be backpatched to even older releases. > > > But IMO we should do that with a test case that demonstrates that there is > > > indeed a bug. > > > > 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).
That should work in 9.2 as well, although its slightly more complicated. You just need a indisready && !indisvalid index and the foreign key will happily be created. Easy enough to achieve with two sessions. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers