Re: Serializable Isolation without blocking - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Serializable Isolation without blocking
Date
Msg-id 4B3E02E6020000250002DC40@gw.wicourts.gov
Whole thread Raw
In response to Serializable Isolation without blocking  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
"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


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: win32 socket definition
Next
From: Kris Jurka
Date:
Subject: Re: Cancelling idle in transaction state