Wrong assert in TransactionGroupUpdateXidStatus - Mailing list pgsql-hackers

From Dilip Kumar
Subject Wrong assert in TransactionGroupUpdateXidStatus
Date
Msg-id CAFiTN-s5=uJw-Z6JC9gcqtBSjXsrHnU63PXBrA=pnBjqnkm5UA@mail.gmail.com
Whole thread Raw
Responses Re: Wrong assert in TransactionGroupUpdateXidStatus  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
While testing, my colleague Vignesh has hit an assert in
TransactionGroupUpdateXidStatus.  But that is not reproducible.  After
some analysis and code review, I have found the reason for the same.

As shown in the below code, there is an assert in
TransactionGroupUpdateXidStatus, which assumes that an overflowed
transaction can never get registered for the group update.  But,
actually, that is not true because while registering the transaction
for group update, we only check how many committed children this
transaction has because all aborted sub-transaction would have already
updated their status.  So if the transaction once overflowed but later
all its children are aborted (i.e remaining committed children are <=
THRESHOLD_SUBTRANS_CLOG_OPT) then it will be registered for the group
update.

/*
* Overflowed transactions should not use group XID status update
* mechanism.
*/
Assert(!pgxact->overflowed);

A solution could be either we remove this assert or change this assert
to Assert(pgxact->nxids <= THRESHOLD_SUBTRANS_CLOG_OPT);

Note:   I could not come up with the reproducible test case as we can
not ensure whether a backend will try to group updates or not because
that depends upon whether it gets the CLogControlLock or not.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: [HACKERS] WAL logging problem in 9.4.3?
Next
From: Noah Misch
Date:
Subject: Re: Windows UTF-8, non-ICU collation trouble