Re: sequencesync worker race with REFRESH SEQUENCES

On Fri, Jul 10, 2026 at 10:22 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
>
> Fable 5 also wrote a lot more that neither it nor I confirmed by test case
> construction. I'm attaching the report; feel free to disregard. Finding-2
> about default_transaction_read_only=on looks worth fixing if true,
>

Agreed on Finding-2 as well. The issue is that the sequencesync
worker sets the value via SetSequence(), which calls
PreventCommandIfReadOnly("setval()") for non-temp sequences, so with
"default_transaction_read_only=on" on the subscriber the worker's
transaction is read-only and sequence sync fails and never reaches
READY. Table apply is unaffected only because
ExecSimpleRelationInsert() bypasses the executor's
ExecCheckXactReadOnly() path which is an undocumented, untested detail
rather than a stated guarantee.

For a minimal backpatch, we can force the sequencesync worker to run
read-write (e.g. set default_transaction_read_only=off for its session
at startup) so it matches table apply, plus a test that sets the GUC
on the subscriber and verifies sequences reach READY. Separately, it's
worth documenting that logical replication apply is exempt from
default_transaction_read_only — it's a per-transaction default meant
to guard user writes and never makes the node physically read-only —
and making that exemption explicit for all logical replication workers
so tables no longer rely on the bypass. What do you think?

--
With Regards,
Amit Kapila.