"Kevin Grittner" wrote: > Jeff Davis wrote: > >> 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 Hmmm... Or do we? If both sides were careful to record what they're doing before checking for a conflict, the pin might be enough. I'll check for that. In at least one of those moves I was moving the predicate lock acquisition from after the conflict check to before, but maybe I didn't need to move it quite so far.... -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
