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

From Amit Kapila
Subject Re: Wrong assert in TransactionGroupUpdateXidStatus
Date
Msg-id CAA4eK1+E5uKMcds_kJ_3zq5RzswnDA9q8QLdD-AF7mBktoWBVQ@mail.gmail.com
Whole thread Raw
In response to Re: Wrong assert in TransactionGroupUpdateXidStatus  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Wrong assert in TransactionGroupUpdateXidStatus
List pgsql-hackers
On Thu, Dec 12, 2019 at 8:44 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> 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).
>

Do you think we need such an Assert after having StaticAssert for
(THRESHOLD_SUBTRANS_CLOG_OPT <= PGPROC_MAX_CACHED_SUBXIDS)  and then
an if statement containing (nsubxids <= THRESHOLD_SUBTRANS_CLOG_OPT)
just before this Assert?  Sure, we can keep this for extra safety, but
I don't see the need for it.


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.
Next
From: Thomas Munro
Date:
Subject: Re: shared tempfile was not removed on statement_timeout (unreproducible)