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

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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Neil Padgett <npadgett(at)redhat(dot)com>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, "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-30 02:49:28
Message-ID: 200107300249.f6U2nSr23825@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
> On Mon, 30 Jul 2001, Hiroshi Inoue wrote:
> 
> > I have a question.
> > What will happen when the second table is locked for a long time
> > though the first table isn't locked ?
> 
> Consider the case:
> 
> LOCK a,b;
> 
> Assume a is free (i.e. not locked), but b is busy (i.e. locked).
> 
> First the system will do a blocking lock attempt on a, which will return
> immediately, since a was free. Table a is now locked. Now, the system will
> try a non-blocking lock on b. But, b is busy so the lock attempt will fail
> immediately (since the lock attempt was non-blocking). So, the system will
> back off, and the lock on a is released.
> 
> Next, a blocking lock attempt will be made on b. (Since it was busy last
> time, we want to wait for it to become free.) The lock call will block
> until b becomes free. At that time, the lock attempt will return, and b
> will be locked. Then, a non-blocking lock attempt will be made on table a.
> (Recall that we don't have a lock on it, since we released it during
> back-off earlier.) Assuming a is still free, it will be locked and the
> LOCK command will complete. Otherwise, if a is busy, the lock attempt will
> then restart with a blocking lock attempt on a. The procedure will
> continue until all tables are free to lock.
> 
> In summary, no locks are held while waiting for tables to become free --
> in essence, the tables are locked all at once, once all tables in the
> LOCK statement are free.

The more I think about it the more I like it.  I never would have
thought of the idea myself.

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

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-07-30 03:19:16
Subject: Re: From TODO, XML?
Previous:From: Neil PadgettDate: 2001-07-30 00:30:57
Subject: Re: Revised Patch to allow multiple table locks in "Unison"

pgsql-patches by date

Next:From: Tom LaneDate: 2001-07-30 03:25:41
Subject: Re: Revised Patch to allow multiple table locks in "Unison"
Previous:From: Neil PadgettDate: 2001-07-30 00:30:57
Subject: Re: Revised Patch to allow multiple table locks in "Unison"

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