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


---------------------------(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

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------


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


>
> ---------------------------(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. +

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://mail.postgresql.org/mj/mj_www...tra=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. +

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

Bruce Momjian wrote:
> 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.
>


No problem, thanks for passing along the feedback - I was primarily
interested in that (as I figured there was probably a reason why this
had not been tried!).

Best wishes

Mark


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