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
