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 after a crash. You would be
* wrong however: we have just written either a TransactionId or a
* MultiXactId that may never have been seen on disk before, and we need
* to make sure that there are XLOG entries covering those ID numbers.
* Else the 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 or 2PC 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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
