Skip site navigation (1) Skip section navigation (2)

Re: Revised Patch to allow multiple table locks in "Unison"

From: Neil Padgett <npadgett(at)redhat(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "pgsql-patches(at)postgresql(dot)org" <pgsql-patches(at)postgresql(dot)org>, Liam Stewart <liams(at)redhat(dot)com>, Fernando Nasser <fnasser(at)redhat(dot)com>
Subject: Re: Revised Patch to allow multiple table locks in "Unison"
Date: 2001-07-27 18:36:25
Message-ID: 3B61B4A9.9AD60EE3@redhat.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Bruce Momjian wrote:
> 
> The problem with this patch is that it doesn't always lock the tables in
> the order supplied by the user, leading to possible deadlock.  My guess
> is that you need to try locking A, B, C and if B hangs, I think you need
> to sleep on B, and when you get it, release the lock on B and try A, B,
> C again.  I know this is a pain and could fail multiple times, but I
> think we have to do it this ay.
> 

Deadlocks are not possible with this patch. The four conditions needed
for deadlock are (according to Operating Systems: Internals and Design
Principles, 4th Ed. by W. Stallings):

1. Mutual exclusion: Only one process may use a resource at a time.
2. Hold and wait: A process may hold allocated resources while awaiting
assignment of others.
3. No preemption: No resources can be forcibly removed from a process
holding it.
4. Circular wait:  A closed chain of processes exists, such that each
process holds at least one resource needed by the next process in the
chain.

For deadlock prevention one needs only to prevent the existence of
at least one of the four conditions. 


The patch code never holds any of requested locks, while waiting for a 
locked relation to become free. If a lock on all tables in the lock list
cannot be acquired at once, it backs off and releases all locks.

Stallings writes about preventing condition 3: "This condition can be
prevented in several ways. [. . .] [One way is to require that,] if a
process holding certain resources is denied a further request, that
process must release its original resources and, if necessary, request
them again together with the additional resources." 

This is exactly what the patch does. Observe that if one lock is not
available, the patch releases all locks so far acquired, and then
acquires
the locks again. Hence, condition 3 is prevented, and so deadlock is
prevented.

Neil

p.s. Is this mailing list always this slow?

-- 
Neil Padgett
Red Hat Canada Ltd.                       E-Mail:  npadgett(at)redhat(dot)com
2323 Yonge Street, Suite #300, 
Toronto, ON  M4P 2C9

In response to

Responses

pgsql-hackers by date

Next:From: Larry RosenmanDate: 2001-07-27 19:49:13
Subject: config.guess on OpenUnix 8...
Previous:From: John GrayDate: 2001-07-27 18:33:54
Subject: Re: Re: Re: Storing XML in PostgreSQL

pgsql-patches by date

Next:From: Bruce MomjianDate: 2001-07-29 05:08:02
Subject: Re: Revised Patch to allow multiple table locks in "Unison"
Previous:From: Jason TishlerDate: 2001-07-27 17:56:08
Subject: Re: libpq.dll (resend)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group