Tom Lane wrote: > Alvaro Herrera <[email protected]> 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 -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
