On Sun, May 9, 2021 at 6:30 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
> > I think that GUCs that aren't listed in config.sgml need to be
> > UNGROUPED; it's just confusing to show them as part of a group
> > when they're not in that group according to the docs. Also,
> > it's almost true that presence of GUC_NO_SHOW_ALL correlates
> > exactly with being UNGROUPED. The couple of exceptions are
> > legacy entries that perhaps should have been changed when they
> > were de-documented.
>
> I think the GUCs that have the GUC_NO_SHOW_ALL flag in guc.c, are not
> showing up in pg_settings output along with show all and they are also
> not mentioned in the config.sgml. Even if they aren't categorized
> under UNGROUPED in guc.c that's not visible to the users. Therefore,
> IMO we can retain the transaction_deferrable, transaction_isolation,
> transaction_read_only category as is i.e. CLIENT_CONN_STATEMENT, just
> add GUC_NO_SHOW_ALL flag and maybe a comment "/* Not for general use
> --- used by START TRANSACTION ISOLATION LEVEL */.
Added GUC_NO_SHOW_ALL flag to transaction_deferrable,
transaction_isolation and transaction_read_only.
> > After thinking about it, I think it's fine if the guc.c string is a
> > shortened form of the config.sgml section title. For instance,
> > I don't feel a need to make "Reporting and Logging" match the docs'
> > "Error Reporting and Logging". But places where it's just randomly
> > different, like "Query Tuning" vs. "Query Planning", probably
> > should be fixed to avoid confusion.
>
> +1 to change Query Planning in docs to Query Tuning to match in guc.c.
>
> Remaining seems fine: (in guc.c, in docs) --> (Resource Usage,
> Resource Consumption), (Write-Ahead Log, Write Ahead Log), (Query
> Tuning, Query Planning), (Reporting and Logging, Error Reporting and
> Logging), (Statistics, Run-time Statistics), (Autovacuum, Automatic
> Vacuuming)
Changed "Query Planning" in the config.sgml to "Query Tuning".
Attaching a small patch with the above changes.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com