Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@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
