BUG #16989: parameter track_commit_timestamp's category problem
The following bug has been logged on the website:
Bug reference: 16989
Logged by: yanliang lei
Email address: leiyanliang@highgo.com
PostgreSQL version: 13.1
Operating system: CentOS7.6
Description:
In the following sql statement, parameter track_commit_timestamp's category
is Replication,and this “Replication” is a first-level category,and this
“Replication”has four second-level categories。
postgres=# select category from pg_settings where
name='track_commit_timestamp';
-[ RECORD 1 ]---------
category | Replication
postgres=#
In the document( postgresql.org/docs/13/runtime-config-replication.html),
parameter track_commit_timestamp is in the “Sending Servers” category
,and,this “Sending Servers” is a second-level category。
so, what is the track_commit_timestamp’s category?
On Fri, Apr 30, 2021 at 2:38 PM PG Bug reporting form
<noreply@postgresql.org> wrote:
The following bug has been logged on the website:
Bug reference: 16989
Logged by: yanliang lei
Email address: leiyanliang@highgo.com
PostgreSQL version: 13.1
Operating system: CentOS7.6
Description:In the following sql statement, parameter track_commit_timestamp's category
is Replication,and this “Replication” is a first-level category,and this
“Replication”has four second-level categories。postgres=# select category from pg_settings where
name='track_commit_timestamp';
-[ RECORD 1 ]---------
category | Replicationpostgres=#
In the document( postgresql.org/docs/13/runtime-config-replication.html),
parameter track_commit_timestamp is in the “Sending Servers” category
,and,this “Sending Servers” is a second-level category。so, what is the track_commit_timestamp’s category?
Thanks for reporting. It looks like it is correctly categorized in the
docs under "Replication / Sending Servers", whereas as in the code
guc.c, it is still put under "Replication". You may want to check the
thread at [1]/messages/by-id/20210413123139.GE6091@telsasoft.com where it's being actively discussed and Justin Pryzby
has a patch for fixing this.
[1]: /messages/by-id/20210413123139.GE6091@telsasoft.com
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com