From: | Fabrice Chapuis <fabrice636861(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | synchronized_standby_slots used in logical replication |
Date: | 2025-06-04 10:30:48 |
Message-ID: | CAA5-nLDvnqGtBsKu4T_s-cS+dGbpSLEzRwgep1XfYzGhQ4o65A@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I'm working with *logical replication* in a PostgreSQL 17 setup, and I'm
exploring the new synchronized_standby_slots parameter to make replication
slots failover safe in a highly available environment using physical
standby nodes managed by Patroni.
While testing this feature, I encountered a blocking behavior, when a *standby
is listed in synchronized_standby_slots* and that standby goes
offline, *logical
replication on the primary stops progressing*. From what I understand, the
primary node waits for the standby to acknowledge received wal records,
effectively stalling WAL decoding for the logical slot. I noticed that the
failover slot on the standby continue to be synced.
This raises several questions about the *tradeoffs and implications* of
using this feature:
- What are the *risks or limitations* if synchronized_standby_slots is *left
empty* (the default)? Is there a risk of data loss or inconsistency for
logical subscribers in such cases?
- Is it expected behavior that *any failure of a standby listed in
synchronized_standby_slots stalls logical decoding* on the primary? If
so, are there any ways to *avoid blocking* WAL decoding while still
having slot synchronization?
- Patroni is managing FO slots better than native Postgres
impletmentation?
Thanks for helping on those points
Regards,
Fabrice
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2025-06-04 10:39:41 | Re: Custom Glibc collation version strings under LOCPATH |
Previous Message | shveta malik | 2025-06-04 10:25:40 | Re: Conflict detection for update_deleted in logical replication |