Re: Issue with logical replication slot during switchover

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: shveta malik <shveta(dot)malik(at)gmail(dot)com>
Cc: Alexander Kukushkin <cyberdemn(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Fabrice Chapuis <fabrice636861(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>
Subject: Re: Issue with logical replication slot during switchover
Date: 2025-11-14 06:09:35
Message-ID: CAD21AoDT+SDc54ZhNFo9yC4GZ8Xdghb1ieaqNwGg=ruZbHD2sQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 13, 2025 at 7:16 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Thu, Nov 13, 2025 at 6:39 PM Alexander Kukushkin <cyberdemn(at)gmail(dot)com> wrote:
> >
> >
> >
> >> But the system can die/crash before shutdown.
> >
> >
> > You mean it will not write WAL?
> > When a logical replication slot is created we build a snapshot and also write to WAL:
> > postgres=# select pg_current_wal_insert_lsn(); select pg_create_logical_replication_slot('foo', 'pgoutput'); select pg_current_wal_insert_lsn();
> > pg_current_wal_insert_lsn
> > ---------------------------
> > 0/37F96F8
> > (1 row)
> >
> > pg_create_logical_replication_slot
> > ------------------------------------
> > (foo,0/37F9730)
> > (1 row)
> >
> > pg_current_wal_insert_lsn
> > ---------------------------
> > 0/37F9730
> > (1 row)
> >
> > Only after that slot is marked as persistent.
> >
>
> There can be a scenario where a replication slot is dropped and
> recreated, and its WAL is also replicated to the standby. However,
> before the new slot state can be synchronized via slotsync, the
> primary crashes and the standby is promoted. Later, the user manually
> reconfigures the old primary to follow the newly promoted standby (no
> pg-rewind in play). I was wondering whether in such a case, would it
> be a good idea to overwrite the newly created slot on old primary with
> promoted-standby's synced slot (old one) by default? Thoughts?

I think it's an extremely rare or a mostly wrong operation that after
failover (i.e., the old primary didn't shutdown gracefully) users have
the old primar rejoin to the replication as the new standby without
pg_rewind. I guess that pg_rewind should practically be used unless
the primary server gracefully shutdowns (i.e., in switchover case). In
failover cases, pg_rewind launches the server in single-user mode to
run the crash recovery, advancing its LSN and cleaning all existing
replication slots after rewinding the server. So I think that the
reported issue doesn't happen in failover cases and we can focus on
failover cases.

Regards,

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Japin Li 2025-11-14 06:22:44 Re: [WIP]Vertical Clustered Index (columnar store extension) - take2
Previous Message Michael Paquier 2025-11-14 06:04:25 Re: pgsql: Drop unnamed portal immediately after execution to completion