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

From Masahiko Sawada
Subject Re: Session in aborted transaction misses effective_wal_level change
Date
Msg-id CAD21AoBbSQE1=XhaEy70B-fH4-UPnAqXAkMj4qE+ftOic_dyYw@mail.gmail.com
Whole thread
In response to RE: Session in aborted transaction misses effective_wal_level change  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
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've attached the updated patch. I'm going to push it on Monday,
barring objections.

Regards,

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

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Fix apply worker crash when subscriber table has only a deferrable primary key
Next
From: Matthias van de Meent
Date:
Subject: Re: Costing for parallel scans with few/single row produced in the outer side