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

Well, it seems to me that there are a number of places this can be taken
then:

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
Oracle compatibility.
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
also
doable, but lose some of the advantages of the command. 5 is reasonable,
but disappointing, especially from a user standpoint.

Thoughts?

Neil

--
Neil Padgett
Red Hat Canada Ltd. E-Mail: npadgett(at)redhat(dot)com
2323 Yonge Street, Suite #300,
Toronto, ON M4P 2C9