Re: [PATCH] Support automatic sequence replication

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: Ajin Cherian <itsajin@gmail.com>, shveta malik <shveta.malik@gmail.com>, Ashutosh Sharma <ashu.coek88@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-02-23T05:44:19Z
Lists: pgsql-hackers
On Mon, Feb 23, 2026 at 6:56 AM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> 06.
> Not sure if the issue should be discussed here, but I found that sequences more
> likely to go backward if users use sequences on the subscriber side.
> Previously, the sync could happen based on the request, and users could understand
> the risk. But now everything would be done automatically, thus they may be
> surprised more.
>
> Should we consider some ratchet mechanisms, or retain it now because it's not
> expected usage?
>

We discussed this case upthread. We ideally can handle it via
conflict/resolution strategy or simply avoid updating the sequences
that are synced from the publisher. If we do later it would be tricky
because we need to maintain a persistent state and then after
failover, that state should be cleared. We discussed to have it
documented that users should use such sequences only during upgrade or
for failover cases, allowing to update it actively on multiple nodes
can lead to inconsistency.

-- 
With Regards,
Amit Kapila.



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Don't include wait_event.h in pgstat.h

  2. Don't include proc.h in shm_mq.h

  3. Fix unsafe RTE_GROUP removal in simplify_EXISTS_query

  4. Add sequence synchronization for logical replication.