Re: Synchronizing slots from primary to standby

On Fri, Mar 1, 2024 at 3:22 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> On Fri, Mar 1, 2024 at 5:11 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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