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 CAA4eK1JgEZKdVYJnaQ-3QJpYgvf+L_zcT5eSPRBcfwfzfzaK0g@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Document XLOG_INCLUDE_XID a little better  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pgsql: Document XLOG_INCLUDE_XID a little better
List pgsql-hackers
On Fri, Oct 1, 2021 at 12:32 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Sep 30, 2021 at 6:08 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > I think we can do better than using XLOG_INCLUDE_XID flag in the
> > record being inserted. We need this flag so that we can mark
> > SubTransaction assigned after XLogInsertRecord()  is successful. We
> > can instead output a flag (say sub_xact_assigned) from
> > XLogRecordAssemble() and pass it to XLogInsertRecord(). Then in
> > XLogInsertRecord(), we can mark SubTransactionAssigned once the record
> > is inserted (after or before calling
> > MarkCurrentTransactionIdLoggedIfAny()).
>
> Isn't there other communication between these routines that just uses
> global variables?
>

AFAICS, there are two possibilities w.r.t global variables: (a) use
curinsert_flags which we are doing now, (b) another is to introduce a
new global variable, set it after we make the association, and then
reset it after we mark SubTransaction assigned and on error. I have
also thought of passing it via XLogCtlInsert but as that is shared by
different processes, it can be set by one process and be read by
another process which we don't want here.

I am not sure if any of these is better than doing this communication
via local variable. Do you have something specific in mind?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: non-superusers are allowed to drop the replication user, but are not allowed to alter or even create them, is that ok?
Next
From: Michael Paquier
Date:
Subject: Re: Incorrect snapshots while promoting hot standby node when 2PC is used