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

From Hiroshi Inoue
Subject Re: Revised Patch to allow multiple table locks in "Unison"
Date
Msg-id 3B64D85D.E8633CB9@tpf.co.jp
Whole thread Raw
In response to Re: Revised Patch to allow multiple table locks in "Unison"  (Neil Padgett <npadgett@redhat.com>)
List pgsql-patches
Neil Padgett wrote:
>
> 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.

Is it paranoid to worry about the followings ?

1) Concurrent 'lock table a, b;' and 'lock table b, a;'
   could last forever in theory ?
2) 'Lock table a,b' could hardly acquire the lock when
   both the table a and b are very frequently accessed.

regards,
Hiroshi Inoue

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Revised Patch to allow multiple table locks in "Unison"
Next
From: Bruce Momjian
Date:
Subject: Re: [INTERFACES] WIN32 MULTIBYTE