Re: Use proc instead of MyProc in ProcArrayGroupClearXid()/TransactionGroupUpdateXidStatus() - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Use proc instead of MyProc in ProcArrayGroupClearXid()/TransactionGroupUpdateXidStatus()
Date
Msg-id CALj2ACWQ5F41tzUYeHcu90F9g6+bsm3Rk09ztwM5vM1bGwBAig@mail.gmail.com
Whole thread Raw
In response to Re: Use proc instead of MyProc in ProcArrayGroupClearXid()/TransactionGroupUpdateXidStatus()  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Tue, Nov 8, 2022 at 11:59 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Nov 7, 2022 at 3:17 PM rajesh singarapu <rajesh.rs0541@gmail.com> wrote:
> >
> > In both TransactionGroupUpdateXidStatus and ProcArrayGroupClearXid
> > global MyProc is used. for consistency, replaced with a function local variable.
> >
>
> In ProcArrayGroupClearXid(), currently, we always pass MyProc as proc,
> so the change suggested by you will work but I think if in the future
> someone calls it with a different proc, then the change suggested by
> you won't work.

Well, yes. Do you have any thoughts around such future usages of
ProcArrayGroupClearXid()?

> The change in TransactionGroupUpdateXidStatus() looks
> good but If we don't want to change ProcArrayGroupClearXid() then I am
> not sure if there is much value in making the change in
> TransactionGroupUpdateXidStatus().

AFICS, there are many places in the code that use proc == MyProc (20
instances) or proc != MyProc (6 instances) sorts of things. I think
defining a macro, something like below, is better for readability.
However, I'm concerned that we might have to use it in 26 places.

#define IsPGPROCMine(proc) (proc != NULL && proc == MyProc)
or just
#define IsPGPROCMine(proc) (proc == MyProc)

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock
Next
From: Thomas Munro
Date:
Subject: Re: when the startup process doesn't (logging startup delays)