2010/1/8 Markus Wanner <mar...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers