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
v1-0001-Change-wrong-assert-while-group-updating-xid-stat.patch
Description: Binary data
