Re: Session in aborted transaction misses effective_wal_level change - Mailing list pgsql-hackers

On Sun, Oct 4, 2026 at 8:35 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.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.

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

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com