Re: Revised Patch to allow multiple table locks in "Unison" - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: Revised Patch to allow multiple table locks in "Unison"
Date
Msg-id 200108020145.f721jF000931@candle.pha.pa.us
Whole thread Raw
In response to Re: Revised Patch to allow multiple table locks in "Unison"  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Revised Patch to allow multiple table locks in "Unison"  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
> > This is interesting. I'd like to hear what other people think about
> > this.
>
> I doubt that this works --- it still has the same fundamental problem:
> that you're not telling the lock manager what it needs to know to
> fulfill its responsibility of detecting deadlock.  I believe I can still
> produce a ping-pong undetected deadlock example with the above behavior;
> it'd just take a few more processes.  The issue is that you are
> expecting the lock manager to detect or not detect deadlock, when you
> still have some lock requests up your sleeve that it's not seen yet.
> As long as you can block before presenting them all, it can never work.

I know there has been talk about having this done in the lock manager,
and I know it isn't worth the effort, but I am wondering how you would
do it even if you were doing in the lock manager with more information
available.

You could query all the locks at once but we really can already do that
now.  We could detect deadlock better.  Would that be the only
advantage?

Seems this whole idea maybe wasn't a good one.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

pgsql-patches by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: ODBC Boolean handling
Next
From: Bruce Momjian
Date:
Subject: Re: Patch for Improved Syntax Error Reporting