Re: pgsql: Document XLOG_INCLUDE_XID a little better - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: pgsql: Document XLOG_INCLUDE_XID a little better
Date
Msg-id CAA4eK1+1BPyBK1KAEkzwpm+2nH4i1_xVm-WTgjd+gpxA_kT4SA@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Document XLOG_INCLUDE_XID a little better  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: pgsql: Document XLOG_INCLUDE_XID a little better  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
On Thu, Oct 7, 2021 at 10:46 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Sat, Oct 2, 2021 at 4:16 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Fri, Oct 1, 2021 at 6:24 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > >
> > > On 2021-Oct-01, Amit Kapila wrote:
> >
> > > I think a straight standalone variable (probably a static boolean in
> > > xloginsert.c) might be less confusing.
> >
> > I have written two patches, Approach1 is as you described using a
> > static boolean and Approach2 as a local variable to XLogAssembleRecord
> > as described by Amit, attached both of them for your reference.
> > IMHO, either of these approaches looks cleaner.
> >
>
> I have tried to improve some comments and a variable name in the
> Approach-2 (use local variable) patch and also reverts one of the
> comments introduced by the commit ade24dab97. I am fine if we decide
> to go with Approach-1 as well but personally, I would prefer to keep
> the code consistent with nearby code.
>
> Let me know what you think of the attached?
>

Today, I have looked at this patch again and slightly changed a
comment, one of the function name and variable name. Do, let me know
if you or others have any suggestions for better names or otherwise? I
think we should backpatch this to 14 as well where this code was
introduced.

-- 
With Regards,
Amit Kapila.

Attachment

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: prion failed with ERROR: missing chunk number 0 for toast value 14334 in pg_toast_2619
Next
From: Amul Sul
Date:
Subject: Re: using an end-of-recovery record in all cases