> > 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.
Well, we do tell people to lock things in the same order. If they did
this with two lock statements, they would cause a deadlock. In this
case, they could grab their first lock at the same time, fail on the
second, and wait on the second, get it, fail on the first, and go all
over again. However, they would have to stay synchronized to do this.
If one got out of step it would stop.
Actually, with this new code, we could go back to locking in oid order,
which would eliminate the problem. However, I prefer to do things in
the order specified, at least on the first lock try.
--
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