Re: BUG #3833: Index remains when table is dropped
От | Bruce Momjian |
---|---|
Тема | Re: BUG #3833: Index remains when table is dropped |
Дата | |
Msg-id | 200803220133.m2M1X0b03849@momjian.us обсуждение исходный текст |
Ответ на | Re: BUG #3833: Index remains when table is dropped (Mark Kirkwood <markir@paradise.net.nz>) |
Ответы |
Re: BUG #3833: Index remains when table is dropped
|
Список | pgsql-bugs |
The comment I have from Tom Lane on this patch is: band-aid solution to just one aspect of problem ... so I am afraid I am going to have to reject it. Sorry. --------------------------------------------------------------------------- Mark Kirkwood wrote: > 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 [ text/x-patch is unsupported, treating like TEXT/PLAIN ] > *** 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 majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-bugs по дате отправления: