Session in aborted transaction misses effective_wal_level change

From: Sergei Patiakin <sergei(dot)patiakin(at)enterprisedb(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: msawada(at)postgresql(dot)org
Subject: Session in aborted transaction misses effective_wal_level change
Date: 2026-09-30 17:18:44
Message-ID: CANE55rApeNAFaqxLWrvm-NC0Y5gkrBFZFVaHVYP89AGS2SYMcA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

For an aborted transaction, there is today a gap between the
AtEOXact_LogicalCtl call and the XID being cleared. If an
effective_wal_level change occurs during that gap, the change will be
missed. That means the next transaction on that session will not be
logically decoded.

Attaching a reproducer bash script that demonstrates the missing decoded change.
Attaching a fix that moves the AtEOXact_LogicalCtl call later, closing the gap.

The issue was observed on master (b69356cd789) and REL_19_STABLE
(67c01b84788). It seems it was introduced in 67c20979ce7.

repro.sh output without patch:

> rows committed:
> 1
> 2
> 3
>
> changes decoded from slot s:
> table public.t: INSERT: a[integer]:1
> table public.t: INSERT: a[integer]:3

repro.sh output with patch:

> rows committed:
> 1
> 2
> 3
>
> changes decoded from slot s:
> table public.t: INSERT: a[integer]:1
> table public.t: INSERT: a[integer]:2
> table public.t: INSERT: a[integer]:3

Best regards,
Sergei

Attachment Content-Type Size
repro.sh text/x-sh 1.7 KB
v1-0001-Handle-effective_wal_level-change-in-aborted-tran.patch application/octet-stream 1.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-09-30 17:19:40 Re: REPACK (CONCURRENTLY) can crash a logical decoding session
Previous Message Álvaro Herrera 2026-09-30 17:04:17 Re: ATTACH PARTITION cost grows linearly with pg_constraint size (seqscan in CloneFkReferenced), much worse since not-null constraints are in pg_constraint (PG 18)