SERIALIZABLE looks for chains of rw cases.
When we perform UPDATEs and DELETEs we search for rows and then modify
them. The current implementation views that as a read followed by a
write because we issue PredicateLockTuple() during the index fetch.
Is it correct that a statement that only changes data will add
predicate locks for the rows that it modifies?
PredicateLockTuple() specifically avoids adding an SIRead lock if the
tuple already has a write lock on it, so surely it must also be
correct to skip the SIRead lock if we are just about to update the
row?
I am suggesting that we ignore PredicateLockTuple() for cases where we
are about to update or delete the found tuple.
ISTM that a Before Row Trigger would need to add an SIRead lock since
that is clearly a read.
Thoughts?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
