Re: fix stats_fetch_consistency value in postgresql.conf.sample - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: fix stats_fetch_consistency value in postgresql.conf.sample
Date
Msg-id Zas5Xv0oiKJcOAaY@paquier.xyz
Whole thread Raw
In response to Re: fix stats_fetch_consistency value in postgresql.conf.sample  (vignesh C <vignesh21@gmail.com>)
Responses Re: fix stats_fetch_consistency value in postgresql.conf.sample  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
On Sat, Jan 20, 2024 at 07:59:22AM +0530, vignesh C wrote:
> I'm seeing that there has been no activity in this thread for more
> than 8 months, I'm planning to close this in the current commitfest
> unless someone is planning to take it forward.

Thanks, that seems right to me.

I have been looking again at the patch after seeing your reply (spent
some time looking at it but I could not decide what to do), and I am
not really excited with the amount of new facilities this requires in
the TAP test (especially the list of hardcoded parameters that may
change) and the backend-side changes for the GUC flags as well as the
requirements to make the checks flexible enough to work across initdb
and platform-dependent default values.  In short, I'm happy to let
003_check_guc.pl be what check_guc was able to do (script gone in
cf29a11ef646) for the parameter names.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: add function argument names to regex* functions.
Next
From: Michael Paquier
Date:
Subject: Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()