"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
canbe 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