Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updatedtuple

I found one glitch with our merge of the original dup row fix.  With that corrected AND Alvaro’s Friday fix things are
solid.
No dup’s.  No index corruption.

Thanks so much. 

On 10/10/17, 7:25 PM, "Michael Paquier" <michael.paquier@gmail.com> wrote:
   On Tue, Oct 10, 2017 at 11:14 PM, Alvaro Herrera   <alvherre@alvh.no-ip.org> wrote:   > I was seeing just the
reindexproblem.  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
moreproblems now.      Okay, so that's one person more going to this trend, making three with   Peter and I.      >> If
youare getting the dup rows consider the code in the block in   >> heapam.c that starts with the comment “replace multi
byupdate xid”.   >>   >> When I repro this I find that MultiXactIdGetUpdateXid() returns 0.   >> There is an updater in
themultixact array however the status is   >> MultiXactStatusForNoKeyUpdate and not MultiXactStatusNoKeyUpdate.  I   >>
assumethis 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
acquiredby 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
xidis committed.  This   >> sets XMAX to 0 and that row becomes visible as one of the dups.   >> Interestingly the real
xidof the updater is 122944 and the cutoff_xid   >> is 122945.   >   > I haven't seen this effect. Please keep us
updatedif you're able to   > verify corruption this way.      Me neither. It would be nice to not live long with such a
swordof Damocles.   --    Michael      
 


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers