On Fri, Mar 1, 2024 at 3:22 PM Peter Smith <smithpb2...@gmail.com> wrote: > > On Fri, Mar 1, 2024 at 5:11 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > ... > > + /* > > + * "*" is not accepted as in that case primary will not be able to > > know > > + * for which all standbys to wait for. Even if we have physical > > slots > > + * info, there is no way to confirm whether there is any standby > > + * configured for the known physical slots. > > + */ > > + if (strcmp(*newval, "*") == 0) > > + { > > + GUC_check_errdetail("\"*\" is not accepted for > > standby_slot_names"); > > + return false; > > + } > > > > Why only '*' is checked aside from validate_standby_slots()? I think > > that the doc doesn't mention anything about '*' and '*' cannot be used > > as a replication slot name. So even if we don't have this check, it > > might be no problem. > > > > Hi, a while ago I asked this same question. See [1 #28] for the response..
Thanks. Quoting the response from the email: SplitIdentifierString() does not give error for '*' and '*' can be considered as valid value which if accepted can mislead user that all the standbys's slots are now considered, which is not the case here. So we want to explicitly call out this case i.e. '*' is not accepted as valid value for standby_slot_names. IIUC we're concerned with a case like where the user confused standby_slot_names values with synchronous_standby_names values. Which means we would need to keep thath check consistent with available values of synchronous_standby_names. For example, if we support a regexp for synchronous_standby_names, we will have to update the check so we disallow other special characters. Also, if we add a new replication-related parameter that accepts other special characters as the value in the future, will we want to raise an error also for such values in check_standby_slot_names()? Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com