I encountered this bug recently - and thought I'd have a try at seeing
what might fix it.
Taking an exclusive lock on the to-be-dropped table immediately (i.e in
RemoveRel) seems to be enough to prevent the drop starting while an
index is being created in another session. So it "fixes" the issue -
possible objections that I can think of are:
1/ Not a general solution to multi session dependent drop/create of
objects other than tables (unless we do 2/)
2/ Using this approach in all object dropping code may result in
deadlocks (but is this worse than dangling/mangled objects?)
Now, I'm conscious that there could be other show stopper reasons for
*not* doing this that I have not thought of, but figured I'd post in
case the idea was useful. Thoughts?
Cheers
Mark
*** src/backend/commands/tablecmds.c.orig Wed Jan 2 13:58:05 2008
--- src/backend/commands/tablecmds.c Wed Jan 2 13:46:43 2008
***************
*** 514,519 ****
--- 514,522 ----
object.objectId = relOid;
object.objectSubId = 0;
+ //Try a lock here!
+ LockRelationOid(relOid, ExclusiveLock);
+
performDeletion(&object, behavior);
}
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
