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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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