On Mon, Jan 13, 2025 at 10:22 AM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
>
> Thanks to Álvaro for pointing this out. I didn't think of it.
>
> On Sun, Jan 12, 2025 at 2:21 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> > > On 11 Jan 2025, at 10:02, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> > >> and the GUC grouping in guc_tables.c/h?
> >
> > > I don't know what our policy around this is, and maybe the backpatching hazard
> > > isn't too bad here, but it doesn't entirely seem worth the churn.
> >
> > I think the entire point of that categorization is to line up with the
> > docs, so our policy should be to fix this.
>
> I wrote a patch to reorder postgresql.conf.sample. But when I started
> looking at guc_tables.c, it doesn't seem like those are grouped
> according to the current docs order. Part of this is because some of
> the GUCs have different data types. But this appears to be more than
> that. For example, in master guc_tables.c,
> autovacuum_vacuum_cost_limit and vacuum_cost_limit are together (in
> docs in master they were in different sub-sections). Is guc_tables.c
> meant to be consistent with the ordering in the docs?
Since I didn't hear back about this and I don't see an obvious
alternative reorganization in guc_tables.c, I plan to just push the
attached patch that updates only postgresql.conf.sample.
- Melanie