On Mon, Jan 13, 2025 at 10:22 AM Melanie Plageman <melanieplage...@gmail.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 <t...@sss.pgh.pa.us> wrote: > > > > Daniel Gustafsson <dan...@yesql.se> writes: > > > On 11 Jan 2025, at 10:02, Alvaro Herrera <alvhe...@alvh.no-ip.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
v1-0001-Reorder-vacuum-GUCs-in-postgresql.conf.sample-to-.patch
Description: Binary data
