Bruce Momjian wrote:
>
> > In short, the order has to be user-specified, which pretty much
> > means it had better be as given in the statement. Which raises
> > the significant question of why bother with such a patch at all, as
> > opposed to using a series of LOCK statements as one can do already.
> > (With more flexibility, since separate LOCK statements can specify
> > different lock modes.) What's the rationale for adding such a
> > feature in the first place? I don't see that it's buying anything.
>
> The advantage is that you don't hold lock A while waiting for lock B.
> It gets all the locks at the same time.
Unfortunately, holding A while waiting for B is in essence what the
patch does, and Tom is correct that this isn't what we want. I'm working
on a patch that does things a less greedy way than in the patch I just
posted. The new algorithm grabs all of the locks at once as far as
behaviour goes, and holds nothing while trying, unlike the posted patch
which does hold some locks until all are acquired.
That is, if one user does:
LOCK B
And another tries:
LOCK A,B,C;
Then, with the new method, a third user may obtain locks on table A and
C in the interim. With the previous patch only a lock on C could be
acquired in the interim. (Assuming the OIDs of A, B, C were such that A
< B < C.) Although this functionality was still useful, this new method
should offer greater flexibility. And, the user can do something that
they CAN'T do with a series of lock statements. If the second user were
to instead have used:
LOCK A;
LOCK B;
LOCK C;
, then, the third user wouldn't have been able to lock table A in the
interim. (The same trouble as with the lock holding patch I sent
previously.) Hence, the new syntax allows for the possibility of greater
concurrency. And, this can be done without specialized knowledge of
locking order for every single user accessing the database. Further,
questions of locking "order" are made irrelevant when acquiring a list
of locks, and some deadlock concerns that I tried to deal with in the
first patch are again alleviated.
Neil
p.s. The new method has no reliance on OIDs.
--
Neil Padgett
Red Hat Canada Ltd. E-Mail: npadgett@redhat.com
2323 Yonge Street, Suite #300,
Toronto, ON M4P 2C9
