Re: issue with synchronized_standby_slots - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: issue with synchronized_standby_slots
Date
Msg-id CAA4eK1Jprqfs_URBmZ5=OOL98D05rPiGup1sscWgcCGcWU=9iA@mail.gmail.com
Whole thread Raw
In response to Re: issue with synchronized_standby_slots  (Alexander Kukushkin <cyberdemn@gmail.com>)
Responses RE: issue with synchronized_standby_slots
Re: issue with synchronized_standby_slots
List pgsql-hackers
On Mon, Sep 8, 2025 at 2:56 PM Alexander Kukushkin <cyberdemn@gmail.com> wrote:
>
> Recently we also hit this problem.
>
> I think in a current state check_synchronized_standby_slots() and validate_sync_standby_slots() functions are not
veryuseful: 
> - When the hook is executed from postmaster it only checks that synchronized_standby_slots contains a valid list, but
doesn'tcheck that replication slots exists, because MyProc is NULL. It happens both, on start and on reload. 
> - When executed from other backends set_config_with_handle() is called with elevel = 0, and therefore elevel becomes
DEBUG3,which results in no useful error/warning messages. 
>
> There are a couple of places where check_synchronized_standby_slots() failure is not ignored:
> 1. alter system set synchronized_standby_slots='invalid value';
> 2. Parallel workers, because RestoreGUCState() calls set_config_option_ext()->set_config_with_handle() with
elevel=ERROR.As a result, parallel workers fail to start with the error. 
>
> With parallel workers it is actually even worse - we get the error even in case of standby:
> 1. start standby with synchronized_standby_slots referring to non-existing slots
> 2. SET parallel_setup_cost, parallel_tuple_cost, and min_parallel_table_scan_size to 0
> 3. Run  select * from pg_namespace; and observe following error:
> ERROR:  invalid value for parameter "synchronized_standby_slots": "a1,b1"
> DETAIL:  replication slot "a1" does not exist
> CONTEXT:  while setting parameter "synchronized_standby_slots" to "a1,b1"
> parallel worker
>

I see the same behaviour for default_table_access_method and
default_tablespace. For example, see failure cases:
postgres=# Alter system set default_table_access_method='missing';
ERROR:  invalid value for parameter "default_table_access_method": "missing"
DETAIL:  Table access method "missing" does not exist.

postgres=# SET parallel_setup_cost=0;
SET
postgres=# SET parallel_tuple_cost=0;
SET
postgres=# Set min_parallel_table_scan_size to 0;
SET
postgres=# select * from pg_namespace;
ERROR:  invalid value for parameter "default_table_access_method": "missing"
DETAIL:  Table access method "missing" does not exist.
CONTEXT:  while setting parameter "default_table_access_method" to "missing"
parallel worker

OTOH, there is no ERROR on reload or restart.

It is fair to argue that invalid GUC values should be ignored in
certain cases like parallel query but we should have the same solution
for other similar parameters as well.

As for the synchronized_standby_slots, we can follow the behavior
similar to check_synchronous_standby_names and just give parsing
ERRORs. Any non-existent slot related errors can be given when that
parameter is later used.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: BharatDB
Date:
Subject: Re: Adding skip scan (including MDAM style range skip scan) to nbtree
Next
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: issue with synchronized_standby_slots