Wrong assert in TransactionGroupUpdateXidStatus

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Wrong assert in TransactionGroupUpdateXidStatus
Дата
Msg-id CAFiTN-s5=uJw-Z6JC9gcqtBSjXsrHnU63PXBrA=pnBjqnkm5UA@mail.gmail.com
обсуждение исходный текст
Ответы Re: Wrong assert in TransactionGroupUpdateXidStatus  (Andres Freund <andres@anarazel.de>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: [HACKERS] WAL logging problem in 9.4.3?
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Windows UTF-8, non-ICU collation trouble