Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> *** a/src/backend/storage/lmgr/predicate.c >> --- b/src/backend/storage/lmgr/predicate.c >> *************** >> *** 274,279 **** >> --- 274,280 ---- >> #define SkipSerialization(relation) \ >> ((!IsolationIsSerializable()) \ >> || ((MySerializableXact == InvalidSerializableXact)) \ >> + || (!IsMVCCSnapshot(GetActiveSnapshot())) \ >> || ReleasePredicateLocksIfROSafe() \ >> || SkipPredicateLocksForRelation(relation)) > BTW, am I reading the function names right to suspect that > ReleasePredicateLocksIfROSafe might be something with > side-effects? > Yuck. I'm open to other suggestions on this. Let me explain what's up here. A READ ONLY transaction can have a "safe" snapshot, in which case it doesn't need to acquire predicate locks or participate in dangerous structure detection. We check for this at transaction startup and start the transaction with MySerializableXact set to InvalidSerializableXact in that case, so it would never make it past that test. We also have the new DEFERRABLE transaction property which causes transaction startup to *wait* for a safe snapshot. (SIREAD locks never block anything; this request for a SERIALIZABLE READ ONLY DEFERRABLE transaction is the only blocking introduced in SSI.) But a READ ONLY transaction's snapshot can *become* safe while it is running. We felt it was worthwhile to watch for this and flag the transaction as safe, to minimize predicate lock space used, CPU consumed, LW lock contention, and false positive serialization failures. While this is actually detected, and the transaction flagged as safe, during commit or rollback of a READ WRITE transaction, proper cleanup can only be done (at least without a lot of new mechanism and locking) by the now-safe transaction's process. The points where it makes sense to check this and do the cleanup correspond exactly to the places where this macro is called. We could take ReleasePredicateLocksIfROSafe() out of the SkipSerialization(relation) macro, but we'd need to ensure that these macros are always called as a pair, and even then we wouldn't be calling it in the place where it makes the most sense. So, while this construction does make one squirm a little, it seems a sane accommodation to reality. If anyone can spot a cleaner way to do it, that'd be great. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
