MIME-Version: 1.0
From: Hugo DUBOIS <hdubois@scaleway.com>
Date: Thu, 24 Jul 2025 15:54:00 +0200
Message-ID: 
 <CAH0PTU_pc3oHi__XESF9ZigCyzai1Mo3LsOdFyQA4aUDkm01RA@mail.gmail.com>
Subject: Unexpected Standby Shutdown on sync_replication_slots change
To: pgsql-bugs@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000fcdd73063aad286e"
Archived-At: 
 <https://www.postgresql.org/message-id/CAH0PTU_pc3oHi__XESF9ZigCyzai1Mo3LsOdFyQA4aUDkm01RA%40mail.gmail.com>
Precedence: bulk

--000000000000fcdd73063aad286e
Content-Type: text/plain; charset="UTF-8"

Hello,

I'm not sure if it's a bug but I've encountered an unexpected behavior when
dynamically changing the sync_replication_slots parameter on a PostgreSQL
17 standby server. Instead of logging an error and continuing to run, the
standby instance shuts down with a FATAL error, which is not the
anticipated behavior for a dynamic parameter change, especially when the
documentation doesn't indicate such an outcome.

Steps to Reproduce


   1.

   Set up a physical replication between two PostgreSQL 17.5 instances.
   2.

   Ensure wal_level on the primary (and consequently on the standby) is set
   to replica.
   3.

   Start both the primary and standby instances, confirming replication is
   active.
   4.

   On the *standby* instance, dynamically change the sync_replication_slots
   parameter (I have run the following query: ALTER SYSTEM SET
   sync_replication_slots = 'on'; followed by SELECT pg_reload_conf();)

Expected Behavior

I expected the standby instance to continue running and log an error
message (similar to how hot_standby_feedback behaves when not enabled,
e.g., a loop of LOG: replication slot synchronization requires
"hot_standby_feedback" to be enabled). A FATAL error leading to an
unexpected shutdown for a dynamic parameter change on a running standby is
not the anticipated behavior. The documentation for sync_replication_slots
also doesn't indicate that a misconfiguration or incompatible wal_level
would lead to a shutdown.

Actual Behavior

Upon attempting to set sync_replication_slots to on on the standby with
wal_level set to replica, the standby instance immediately shuts down with
the following log messages:

LOG:  database system is ready to accept read-only connections
LOG:  started streaming WAL from primary at 0/3000000 on timeline 1
LOG:  received SIGHUP, reloading configuration files
LOG:  parameter "sync_replication_slots" changed to "on"
FATAL:  replication slot synchronization requires "wal_level" >= "logical"

Environment


   -

   *PostgreSQL Version:* 17.5

--000000000000fcdd73063aad286e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><p>Hello,</p><p>I&#39;m not sure if it&#39;s a bug bu=
t I&#39;ve encountered an unexpected behavior when dynamically changing the=
 <code>sync_replication_slots</code> parameter on a PostgreSQL 17 standby s=
erver. Instead of logging an error and continuing to run, the standby insta=
nce shuts down with a <code>FATAL</code> error, which is not the anticipate=
d behavior for a dynamic parameter change, especially when the documentatio=
n doesn&#39;t indicate such an outcome.</p><p></p><h3>Steps to Reproduce</h=
3><p></p><ol start=3D"1"><li><p>Set up a physical replication between two P=
ostgreSQL 17.5 instances.</p></li><li><p>Ensure <code>wal_level</code> on t=
he primary (and consequently on the standby) is set to <code>replica</code>=
.</p></li><li><p>Start both the primary and standby instances, confirming r=
eplication is active.</p></li><li><p>On the <b>standby</b> instance, dynami=
cally change the <code>sync_replication_slots</code> parameter (I have run =
the following query:=C2=A0<code>ALTER SYSTEM SET sync_replication_slots =3D=
 &#39;on&#39;;</code> followed by <code>SELECT pg_reload_conf();)</code></p=
></li></ol><p></p><h3>Expected Behavior</h3><p></p><p>I expected the standb=
y instance to continue running and log an error message (similar to how <co=
de>hot_standby_feedback</code> behaves when not enabled, e.g., a loop of=C2=
=A0<code>LOG: replication slot synchronization requires &quot;hot_standby_f=
eedback&quot; to be enabled</code>). A <code>FATAL</code> error leading to =
an unexpected shutdown for a dynamic parameter change on a running standby =
is not the anticipated behavior. The documentation for <code>sync_replicati=
on_slots</code> also doesn&#39;t indicate that a misconfiguration or incomp=
atible <code>wal_level</code> would lead to a shutdown.</p><p></p><h3>Actua=
l Behavior</h3><p></p><p>Upon attempting to set <code>sync_replication_slot=
s</code> to <code>on</code> on the standby with <code>wal_level</code> set =
to <code>replica</code>, the standby instance immediately shuts down with t=
he following log messages:</p><span class=3D"gmail-"><span class=3D"gmail-n=
g-tns-c2485367380-50 gmail-ng-star-inserted"><div class=3D"gmail-code-block=
 gmail-ng-tns-c2485367380-50 gmail-ng-animate-disabled gmail-ng-trigger gma=
il-ng-trigger-codeBlockRevealAnimation"><div class=3D"gmail-formatted-code-=
block-internal-container gmail-ng-tns-c2485367380-50"><div class=3D"gmail-a=
nimated-opacity gmail-ng-tns-c2485367380-50"><pre class=3D"gmail-ng-tns-c24=
85367380-50"><code role=3D"text" class=3D"gmail-code-container gmail-format=
ted gmail-ng-tns-c2485367380-50 gmail-no-decoration-radius">LOG:  database =
system is ready to accept read-only connections
LOG:  started streaming WAL from primary at 0/3000000 on timeline 1
LOG:  received SIGHUP, reloading configuration files
LOG:  parameter &quot;sync_replication_slots&quot; changed to &quot;on&quot=
;
FATAL:  replication slot synchronization requires &quot;wal_level&quot; &gt=
;=3D &quot;logical&quot;
</code></pre></div></div></div></span></span><p></p><h3>Environment</h3><p>=
</p><ul><li><p><b>PostgreSQL Version:</b> 17.5</p></li></ul></div><div dir=
=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"></div=
></div>

--000000000000fcdd73063aad286e--