Proposed patch for xact-vs-multixact bugs
The attached patch fixes the problem discussed here
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00357.php
as well as a related problem that I discovered while working on it:
the sequence
begin;
savepoint x;
select * from foo for update;
release savepoint x;
select * from foo for share;
leaves us holding only share lock not exclusive lock on the selected
tuples. That's because heap_lock_tuple() considered only the
exact-XID-equality case when checking to see if we were requesting
share lock while already holding exclusive lock. We should treat
exclusive lock held under any of the current backend's subtransactions
as not to be overridden.
In addition, this formulation avoids useless buffer-dirtying and WAL
reporting in all cases where the desired lock is already effectively held,
whereas the old code would go through the full pushups anyway.
I've only tested it against HEAD but it will need to be applied to 8.1
as well.
Anyone see any problems?
regards, tom lane
On Thu, 2006-11-16 at 20:23 -0500, Tom Lane wrote:
We should treat
exclusive lock held under any of the current backend's subtransactions
as not to be overridden.
I can't find any clear discussion of this within the docs. I guess if
there were some clear statements on this it would have been uncovered
earlier.
We should say something like "Once a lock has been taken it will be held
until the end of the transaction. Locks obtained after a SAVEPOINT (i.e.
within a subtransaction) will continue to be held even after a RELEASE
SAVEPOINT". Does this also apply if we do a ROLLBACK TO SAVEPOINT?
I'll do some docs for the Concurrency Control section.
Has the same thinking been applied to table level locks also?
LOCK TABLE has same issue maybe?
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com