Re: Session in aborted transaction misses effective_wal_level change

Hi Sawada-san,

On Mon, Oct 05, 2026 at 11:01:50AM -0700, Masahiko Sawada wrote:
> On Sun, Oct 4, 2026 at 8:35 PM Hayato Kuroda (Fujitsu)
> <kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
> >
> > Dear Bertrand, Sawada-san,
> >
> > > I wonder if it wouldn't make more sense to keep this after
> > > XactTopFullTransactionId
> > > is reset, as in v1?
> > >
> > > Indeed, couldn't a barrier be processed during AtCleanup_Memory(), while the
> > > XID is still valid, and set XLogLogicalInfoUpdatePending again after this call?
> >
> > Per my research the function calls MemoryContextCallResetCallbacks(), which can
> > calls the arbitrary functions from core and extensions. So It's possible that a
> > random callback calls CHECK_FOR_INTERRUPTS() and consumes a barrier.
> >
> > I still prefer to put after resetting the XactTopFullTransactionId.
> >
>
> Thank you for the comments. I'm now convinced that we can call it
> after resetting the top-level XID. I was concerned about the
> inconsistency between the AtEOXact_LogicalCtl() calls in
> CommitTransaction() and CleanupTransaction(), but it's fine for them
> to differ, since we're holding interrupts in the former but not in the
> latter. Calling AtEOXact_LogicalCtl() after resetting the top-level
> XID would be more bullet-proof, so let's go with this approach.

Yeah, thanks!

> I've attached the updated patch. Please review it.

LGTM.

Regards,

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