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) > <[email protected]> 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
