On Thu, Sep 18, 2025 at 10:54 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> On Fri, Sep 12, 2025 at 9:12 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> >
> > Hi,
> >
> > While reviewing the patch at [1], I noticed that if primary_slot_name is
> > set to an invalid slot name in postgresql.conf and the configuration file
> > is reloaded, all running postgres processes emit the WARNING message
> > as follows. Isn't this a bug?
> >
> > To fix this issue, GUC_check_errmsg() should be used instead of ereport()
> > when an invalid slot name is found in the setting. Thoughts?
>
> Another simple fix would be to have processes other than the postmaster
> report invalid primary_slot_name at DEBUG3 instead of WARNING.
> In that case, only the postmaster reports it at WARNING, so by default
> only that message appears in the log file. This matches the behavior for
> other GUC parameters with invalid settings.
>
> I've attached a patch implementing this approach. Thought?
This approach unexpectedly suppresses the log message about an invalid
primary_slot_name when it's set with ALTER SYSTEM SET, so it isn't suitable.
Instead, we should use GUC_check_xxx() functions for error reporting
in the GUC check hook.
I've attached a patch that updates the check hook for primary_slot_name
to use GUC_check_errdetail() and GUC_check_errhint(). As with other
GUC parameters, this makes non-postmaster processes log at DEBUG3,
so by default only the postmaster's message appears in the log file.
Regards,
--
Fujii Masao