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@redhat.com
2323 Yonge Street, Suite #300, 
Toronto, ON  M4P 2C9