Re: Wrong assert in TransactionGroupUpdateXidStatus - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Wrong assert in TransactionGroupUpdateXidStatus
Date
Msg-id CA+TgmobktGOfEudrjTcVr3R6wftdWS_ivjYB_pNm=i_XKWiyaw@mail.gmail.com
Whole thread Raw
In response to Re: Wrong assert in TransactionGroupUpdateXidStatus  (Andres Freund <andres@anarazel.de>)
Responses Re: Wrong assert in TransactionGroupUpdateXidStatus  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Tue, Dec 10, 2019 at 4:32 PM Andres Freund <andres@anarazel.de> wrote:
> and then, within an if():
>
>                 /*
>                  * We don't try to do group update optimization if a process has
>                  * overflowed the subxids array in its PGPROC, since in that case we
>                  * don't have a complete list of XIDs for it.
>                  */
>                 Assert(THRESHOLD_SUBTRANS_CLOG_OPT <= PGPROC_MAX_CACHED_SUBXIDS);
>
> Even if these weren't redundant, it can't make sense to test such a
> static condition only within an if? Is it possible this was actually
> intended to test something different?

Based on the comment, I imagine it might've been intended to read
Assert(nsubxids <= PGPROC_MAX_CACHED_SUBXIDS).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Duplicate function call on timestamp2tm
Next
From: Asif Rehman
Date:
Subject: Re: WIP/PoC for parallel backup