2010/1/8 Markus Wanner <markus@bluegap.ch>:
> SIREAD atop predicate locking serves detecting vulnerable edges (I hope
> I'm using that term correctly here) between newly inserted tuples and
> reads, right? I was trying to figure if it would make sense to use
> predicate locking (instead of table or row level locking) as well for
> detecting vulnerable edges between updated or deleted tuples and reads.
AFAICS, detecting a "rw" dependency where the read executes after the
write is rather easy: the writer has created a row version that is not
visible to the reader's snapshot. Therefore, any time a reader reads a
non-last version of a row, there is a rw dependency between it and the
creators of any newer versions.
Btw, rw dependencies are the only thing that needs to be checked under
SI, as "wr" and "ww" dependencies never lead to problems: one can only
see (or update) a certain row version using a transaction that has
taken its snapshot after the writing transaction already committed.
Therefore, the "must be before" relationship between such transactions
is trivially satisfied. (I assume here that PG's non-SI-compatible
behavior of not always rollbacking any transaction that writes to a
non-last version will be disabled in serializable mode.)
Nicolas