From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #3833: Index remains when table is dropped |
Date: | 2008-01-03 21:56:46 |
Message-ID: | 477D5A1E.4090807@paradise.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
Attachment | Content-Type | Size |
---|---|---|
tablecmds.c.patch | text/x-patch | 352 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-01-04 02:29:32 | Re: Duplicate values found when reindexing unique index |
Previous Message | Mason Hale | 2008-01-03 19:58:23 | Re: Duplicate values found when reindexing unique index |