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

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)
> <kuroda.hayato@fujitsu.com> 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