Horton

Thread

Commits

  1. doc: Move synchronized_standby_slots to "Primary Server" section.

  1. Placement of synchronized_standby_slots description in config.sgml

    Fujii Masao <masao.fujii@gmail.com> — 2026-01-23T10:21:51Z

    Hi,

synchronized_standby_slots is defined in guc_parameter.dat as part of
the REPLICATION_PRIMARY group and appears under the "Primary Server"
section in postgresql.conf.sample. However, in the documentation
its description is placed under the "Sending Servers" section.

Given this, it seems the description should also be under "Primary Server"
in the documentation. I've attached a patch that moves it there.

Alternatively, if synchronized_standby_slots is intended to be set also
on a standby in cascading replication setups, then the current documentation
placement may be correct, and instead guc_parameter.dat and
postgresql.conf.sample should be updated. My understanding, though,
is that this parameter is normally set only on the primary. Right?

Regards,

-- 
Fujii Masao

  2. Re: Placement of synchronized_standby_slots description in config.sgml

    Shinya Kato <shinya11.kato@gmail.com> — 2026-02-05T06:47:04Z

    On Fri, Jan 23, 2026 at 7:22 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> Hi,
>
> synchronized_standby_slots is defined in guc_parameter.dat as part of
> the REPLICATION_PRIMARY group and appears under the "Primary Server"
> section in postgresql.conf.sample. However, in the documentation
> its description is placed under the "Sending Servers" section.
>
> Given this, it seems the description should also be under "Primary Server"
> in the documentation. I've attached a patch that moves it there.

Thank you for the patch! The patch LGTM.

> Alternatively, if synchronized_standby_slots is intended to be set also
> on a standby in cascading replication setups, then the current documentation
> placement may be correct, and instead guc_parameter.dat and
> postgresql.conf.sample should be updated. My understanding, though,
> is that this parameter is normally set only on the primary. Right?

You're right. PhysicalWakeupLogicalWalSnd() in walsender.c has this check:

    /*
     * If we are running in a standby, there is no need to wake up walsenders.
     * This is because we do not support syncing slots to cascading standbys,
     * so, there are no walsenders waiting for standbys to catch up.
     */
    if (RecoveryInProgress())
        return;

So this parameter is only meaningful on the primary.

-- 
Best regards,
Shinya Kato
NTT OSS Center

  3. Re: Placement of synchronized_standby_slots description in config.sgml

    Fujii Masao <masao.fujii@gmail.com> — 2026-02-06T00:43:50Z

    On Thu, Feb 5, 2026 at 3:47 PM Shinya Kato <shinya11.kato@gmail.com> wrote:
>
> On Fri, Jan 23, 2026 at 7:22 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> >
> > Hi,
> >
> > synchronized_standby_slots is defined in guc_parameter.dat as part of
> > the REPLICATION_PRIMARY group and appears under the "Primary Server"
> > section in postgresql.conf.sample. However, in the documentation
> > its description is placed under the "Sending Servers" section.
> >
> > Given this, it seems the description should also be under "Primary Server"
> > in the documentation. I've attached a patch that moves it there.
>
> Thank you for the patch! The patch LGTM.

Thanks for the review! I've pushed the patch.


> > Alternatively, if synchronized_standby_slots is intended to be set also
> > on a standby in cascading replication setups, then the current documentation
> > placement may be correct, and instead guc_parameter.dat and
> > postgresql.conf.sample should be updated. My understanding, though,
> > is that this parameter is normally set only on the primary. Right?
>
> You're right. PhysicalWakeupLogicalWalSnd() in walsender.c has this check:
>
>     /*
>      * If we are running in a standby, there is no need to wake up walsenders.
>      * This is because we do not support syncing slots to cascading standbys,
>      * so, there are no walsenders waiting for standbys to catch up.
>      */
>     if (RecoveryInProgress())
>         return;
>
> So this parameter is only meaningful on the primary.

Thanks for confirming this!

Regards,

-- 
Fujii Masao