Re: pgsql: Fix WAL replay of locking an updated tuple - Mailing list pgsql-committers

From Alvaro Herrera
Subject Re: pgsql: Fix WAL replay of locking an updated tuple
Date
Msg-id 20140227144727.GP4759@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: pgsql: Fix WAL replay of locking an updated tuple  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > Fix WAL replay of locking an updated tuple
>
> The test added by this patch certainly looks like it's backwards.
> Shouldn't you be clearing HOT_UPDATED only if the tuple is *not*
> XMAX_IS_LOCKED_ONLY?
>
> If the code is actually correct as written, then I think that test
> macro is very unfortunately named.

I don't understand.  Note that this is about replaying a tuple lock
operation; if the tuple we're locking had been updated by another
transaction, then during the lock operation we don't want to touch
either HOT_UPDATED or t_ctid, because they contain values that are valid
per the pre-existing update.  We are assuming that those values are
correctly set prior to this xlog routine touching it (the replay of the
update must have already set them.)

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


pgsql-committers by date:

Previous
From: Alvaro Herrera
Date:
Subject: pgsql: doc: bgw_main takes a Datum argument, not void *.
Next
From: Andres Freund
Date:
Subject: Re: pgsql: Fix WAL replay of locking an updated tuple