From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Fix WAL replay of locking an updated tuple |
Date: | 2014-02-27 14:47:27 |
Message-ID: | 20140227144727.GP4759@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-02-27 14:47:45 | Re: pgsql: Fix WAL replay of locking an updated tuple |
Previous Message | Alvaro Herrera | 2014-02-27 14:43:18 | pgsql: doc: bgw_main takes a Datum argument, not void *. |