Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: "Wood, Dan" <hexpert(at)amazon(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, "Wong, Yi Wen" <yiwong(at)amazon(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
Date: 2017-10-10 14:14:44
Message-ID: 20171010141444.s5tadnstsednska6@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Wood, Dan wrote:
> I’m unclear on what is being repro’d in 9.6. Are you getting the
> duplicate rows problem or just the reindex problem? Are you testing
> with asserts enabled(I’m not)?

I was seeing just the reindex problem. I don't see any more dups.

But I've tried to reproduce it afresh now, and let it run for a long
time and nothing happened. Maybe I made a mistake last week and
ran an unfixed version. I don't see any more problems now.

> If you are getting the dup rows consider the code in the block in
> heapam.c that starts with the comment “replace multi by update xid”.
>
> When I repro this I find that MultiXactIdGetUpdateXid() returns 0.
> There is an updater in the multixact array however the status is
> MultiXactStatusForNoKeyUpdate and not MultiXactStatusNoKeyUpdate. I
> assume this is a preliminary status before the following row in the
> hot chain has it’s multixact set to NoKeyUpdate.

Yes, the "For" version is the locker version rather than the actual
update. That lock is acquired by EvalPlanQual locking the row just
before doing the update. I think GetUpdateXid has no reason to return
such an Xid, since it's not an update.

> Since a 0 is returned this does precede cutoff_xid and
> TransactionIdDidCommit(0) will return false. This ends up aborting
> the multixact on the row even though the real xid is committed. This
> sets XMAX to 0 and that row becomes visible as one of the dups.
> Interestingly the real xid of the updater is 122944 and the cutoff_xid
> is 122945.

I haven't seen this effect. Please keep us updated if you're able to
verify corruption this way.

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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2017-10-10 14:18:00 pgsql: Use lower-case SGML attribute values
Previous Message Tom Lane 2017-10-10 04:55:14 Re: pgsql: Add pg_strnlen() a portable implementation of strlen.

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2017-10-10 15:22:28 Re: Proposal: Local indexes for partitioned table
Previous Message Gourav Kumar 2017-10-10 13:59:24 How does postgres store the join predicate for a relation in a given query