On Fri, Nov 3, 2023 at 1:11 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Nov 2, 2023 at 2:36 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Thu, Nov 2, 2023 at 11:32 AM Michael Paquier <michael@paquier.xyz> wrote:
> > >
> > > On Thu, Nov 02, 2023 at 02:32:07PM +1100, Peter Smith wrote:
> > > > On Thu, Nov 2, 2023 at 2:25 PM Peter Smith <smithpb2250@gmail.com> wrote:
> > > >> Checking this patch yesterday prompted me to create a new thread
> > > >> questioning the inconsistencies of the "GUC names in messages". In
> > > >> that thread, Tom Lane replied and gave some background information [1]
> > > >> about the GUC name embedding versus substitution. In hindsight, I
> > > >> think your original message was fine as-is, but there seem to be
> > > >> examples of every kind of style, so whatever you do would have some
> > > >> precedent.
> > > >>
> > > >> The patch v4 LGTM.
> > > >
> > > > To clarify, all the current code LGTM, but the patch is still missing
> > > > a guc_hook test case, right?
> > >
> > > - NULL, NULL, NULL
> > > + check_max_slot_wal_keep_size, NULL, NULL
> > >
> > > FWIW, I am +-0 with what you are proposing here. I don't quite get
> > > why one may want to enforce this specific GUC at upgrade.
> > >
> >
> > I also can't think of a good reason to do so but OTOH, I can't imagine
> > all possible scenarios. As this setting is invalid or can cause
> > problems, it seems people favor preventing it. Alvaro also voted in
> > favor of preventing it, so we are considering to proceed with it
> > unless more people think otherwise.
> >
>
> Now, that Michael also committed another similar change in commit
> 7021d3b176, it is better to be consistent in both cases. So, either we
I agree. Both patches are setting a special GUC value at the command
line, and both of them don't want the user to somehow override that.
Since the requirements are the same, I felt the implementations
(regardless if they use a guc hook or something else) should also be
done the same way. Yesterday I posted a review comment on the other
thread [1] (#2c) trying to express the same point about consistency.
======
[1] https://www.postgresql.org/message-id/CAHut%2BPsCzt%3DO3_xkyrskaZ3SMxaXoN4L5Z5CgvaGPNx3mXXxOQ%40mail.gmail.com
Kind Regards,
Peter Smith.
Fujitsu Australia
