Hi Sawada-san, On Fri, Oct 02, 2026 at 01:54:04PM -0700, Masahiko Sawada wrote: > On Wed, Sep 30, 2026 at 11:28 PM Hayato Kuroda (Fujitsu) > <[email protected]> wrote: > > > > Dear Sawada-san, Serigei, > > > > Good catch, I have also been seeing and considering the test, but > > Sawada-san is faster. > > > > > The fix looks good to me. We need to check and update XLogLogicalInfo > > > in every place where we reset the top-level transaction id. > > > > > > I've updated the patch with the regression tests. Please review it. > > > > Confirmed the test fails on HEAD and pass after the patch. > > There might be idea to put the function after the "nParallelCurrentXids = > > 0;" > > even in the CommitTransaction() and PrepareTransaction(), which is same as > > CleanupTransaction(). But any places are OK for me. > > > > LGTM. > > Thank you for reviewing the patch. > > I'd rather move AtEOXact_LogicalCtl() to before resetting > CurrentResourceOwner. I think it should work fine too and caon deal > with your concern.
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? Unless I'm missing something, I don't see AtEOXact_LogicalCtl() itself relying on CurrentResourceOwner. Is there some other reason why it needs to be called before CurrentResourceOwner is reset? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
