On Thu, Mar 27, 2014 at 08:16:13PM -0700, David Johnston wrote:
> Slightly tangential but are the locking operations associated with the
> recent bugfix generated in both (all?) modes or only hot_standby?
All modes.
> I thought
> it strange that transient locking operations were output with WAL though I
> get it if they are there to support read-only queries.
It is unintuitive. This comment in heap_lock_tuple() attempts to explain:
/* * XLOG stuff. You might think that we don't need an XLOG record because * there is no state change worth restoring
aftera crash. You would be * wrong however: we have just written either a TransactionId or a * MultiXactId that may
neverhave been seen on disk before, and we need * to make sure that there are XLOG entries covering those ID numbers. *
Elsethe same IDs might be re-used after a crash, which would be * disastrous if this page made it to disk before the
crash. Essentially * we have to enforce the WAL log-before-data rule even in this case. * (Also, in a PITR log-shipping
or2PC environment, we have to have XLOG * entries for everything anyway.) */
Another reason not mentioned is torn pages. Locking a tuple updates t_xmax,
t_infomask2 and t_infomask. It's possible for t_xmax to fall on one side of a
page tear and the infomasks to fall on the other side. Writing t_xmax without
writing the corresponding infomasks could cause the tuple to be considered
deleted, not merely locked, after a crash.
