Re: Wrong assert in TransactionGroupUpdateXidStatus

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Wrong assert in TransactionGroupUpdateXidStatus
Date: 2019-12-12 15:09:17
Message-ID: 20191212150917.GA10537@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-Dec-12, Amit Kapila wrote:

> On Thu, Dec 12, 2019 at 6:10 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:

> > The more I look at both these asserts, the less sense they make. Why
> > does clog.c care about PGPROC at all?
>
> It is mainly for group updates. Basically, we want to piggyback the
> procs that are trying to update clog at the same time on the proc
> which got the CLogControlLock. This avoids taking/releasing that lock
> multiple times. See TransactionGroupUpdateXidStatus.

Yeah, I (think I) understand that. My point is that conceptually, the
fact that a PGPROC has overflowed does not really affect clog.c in any
way.

> > Looking at the callers of that routine, nowhere do they concern
> > themselves with whether the overflowed
> > flag has been set or not. It seems to me that the StaticAssert() should
> > be near the PGPROC_MAX_CACHED_SUBXIDS definition, not the SUBTRANS
> > definition (maybe as StaticAssertDecl, as in
> > 201DD0641B056142AC8C6645EC1B5F62014B8E8030(at)SYD1217 )
>
> Sounds reasonable. We can do that once the patch mentioned by you got
> committed. For now, we are planning to just remove the Assert inside
> if() condition. Do you see any problem with that?

Nope.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2019-12-12 15:12:15 Re: Let people set host(no)ssl settings from initdb
Previous Message Tom Lane 2019-12-12 14:41:18 Re: Duplicate function call on timestamp2tm