Well, it seems to me that there are a number of places this can be taken
1. Don't worry about these cases and apply the patch anyways.
The patch will work correctly in most real world situations.
2. Add a counter / timer to detect livelock / alternating deadlock
conditions. If the counter / timer elapses, abort the offending
transaction (i.e. the one doing the multiple locking) and roll back.
The patch then will always work correctly, AFAICT.
3. Go with the original patch I posted.
Aside from not locking in user order (which is a debatable issue), this
patch seems correct.
4. Go with the original patch but sans OID sort. In this case, LOCK a,b;
degrades into a short form for LOCK a; LOCk b; This is still useful for
Satisfies the TODO list item.
5. Go with a major Lock manager overhaul. (which would be added to the
TODO list.) Defer this functionality until then.
A lock manager overhaul will likely take a while so probably it won't
be done for some time. This means the multiple lock syntax will continue
to be missing from PostgreSQL, possibly for several years.
Personally, I think 1 is acceptable, and 2 is a better idea. 3/4 are
doable, but lose some of the advantages of the command. 5 is reasonable,
but disappointing, especially from a user standpoint.
Red Hat Canada Ltd. E-Mail: npadgett(at)redhat(dot)com
2323 Yonge Street, Suite #300,
Toronto, ON M4P 2C9
In response to
pgsql-hackers by date
|Next:||From: Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=||Date: 2001-07-31 19:06:31|
|Subject: Re: Update to 7.1.2 Question...|
|Previous:||From: gabriel||Date: 2001-07-31 18:24:57|
|Subject: Update to 7.1.2 Question...|
pgsql-patches by date
|Next:||From: Tom Lane||Date: 2001-07-31 19:56:39|
|Subject: Re: Revised Patch to allow multiple table locks in "Unison" |
|Previous:||From: Tom Lane||Date: 2001-07-31 18:48:37|
|Subject: Re: Fuzzy matching? |