On Thu, Sep 18, 2025 at 10:54 PM Fujii Masao <[email protected]> wrote: > > On Fri, Sep 12, 2025 at 9:12 PM Fujii Masao <[email protected]> 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
v2-0001-Make-invalid-primary_slot_name-follow-standard-GU.patch
Description: Binary data
