On Fri, Nov 3, 2023 at 1:11 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Thu, Nov 2, 2023 at 2:36 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Thu, Nov 2, 2023 at 11:32 AM Michael Paquier <mich...@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 <smithpb2...@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
