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 [EMAIL PROTECTED] so that your
>        message can get through to the mailing list cleanly

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Reply via email to