Wrong assert in TransactionGroupUpdateXidStatus

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Wrong assert in TransactionGroupUpdateXidStatus
Date: 2019-12-10 08:25:40
Message-ID: CAFiTN-s5=uJw-Z6JC9gcqtBSjXsrHnU63PXBrA=pnBjqnkm5UA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
v1-0001-Change-wrong-assert-while-group-updating-xid-stat.patch application/octet-stream 1.7 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2019-12-10 09:29:19 Re: Windows UTF-8, non-ICU collation trouble
Previous Message Kyotaro Horiguchi 2019-12-10 07:59:25 Re: [HACKERS] WAL logging problem in 9.4.3?