Jeff Davis wrote: > On Sat, 2011-02-05 at 14:43 -0600, Kevin Grittner wrote: >> In working on this I noticed the apparent need to move two calls >> to PredicateLockTuple a little bit to keep them inside the buffer >> lock. Without at least a share lock on the buffer, it seems that >> here is a window where a read could miss the MVCC from a write and >> the write could fail to see the predicate lock. > What does PredicateLockTuple do that needs a share lock? Does a pin > suffice? If one process is reading a tuple and another is writing it (e.g., UPDATE or DELETE) the concern is that we need to be able to guarantee that either the predicate lock appears in time for the writer to see it on the call to CheckForSerializableConflictIn or the reader sees the MVCC changes in CheckForSerializableConflictOut. It's OK if the conflict is detected both ways, but if it's missed both ways then we could have a false negative, allowing anomalies to slip through. It didn't seem to me on review that acquiring the predicate lock after releasing the shared buffer lock (and just having the pin) would be enough to ensure that a write which followed that would see the predicate lock.
reader has pin and shared lock writer increments pin count reader releases shared lock writer acquires exclusive lock writer checks predicate lock and fails to see one reader adds predicate lock we have a problem -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
