Horton

Re: issue with synchronized_standby_slots

Rahila Syed <rahilasyed90@gmail.com>

View thread
From: Rahila Syed <rahilasyed90@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Alexander Kukushkin <cyberdemn@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, Fabrice Chapuis <fabrice636861@gmail.com>, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-11T06:30:20Z
Lists: pgsql-hackers

Attachments

Hi,



>
> BTW, we should also try to conclude on my yesterday's point as to why
> it is okay to have the same behavior for default_tablespace and
> default_table_access_method and not for this parameter? I am asking
> because if we change the current behavior, tomorrow, we can get
> complaints that one expects the old behaviour as that was similar to
> other GUCs like default_tablespace and default_table_access_method.
>
>
Fair point. I haven't examined the validation of GUCs in parallel workers
closely,
but one argument for preventing parallel workers from failing due to an
incorrect
value of synchronized_standby_slots is that a select query works in this
situation
without parallel workers.

Whereas, for incorrect values of default_tablespace and
default_table_access_method,
most commands would fail regardless of whether parallel workers are enabled.

PFA a test for the original bug report on this thread.  This applies on the
v3 version of the patch
that was shared.

Thank you,
Rahila Syed