"Albe Laurenz" wrote: > If I remember right, one necessity for the SIREAD lock technique > was that SIREAD locks taken by a transaction have to be kept after > the transaction has ended. Correct. An SIREAD lock must be held until completion of the last serializable transaction holding a snapshot earlier than the lock transaction's commit.
Exceptions to that are: - If a serializable transaction is rolled back, all SIREAD locks can be immediately released. - If an an ACCESS EXCLUSIVE lock is acquired on the exact same object already locked by an SIREAD lock, the SIREAD lock can be released. (This is an optimization, not a requirement for correctness.) > Won't that require fundamental changes? We already have two different lock methods, one of which already keeps locks past the end of a database transaction. USER locks persist until the session terminates or the lock is explicitly released. Given that, I don't think it would be fair to characterize a third lock method with a third lifespan as a fundamental change -- just another implementation detail. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
