| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Don Seiler <don(at)seiler(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Estimating HugePages Requirements? |
| Date: | 2022-05-11 05:34:25 |
| Message-ID: | YntK4a8ET4dW0E4L@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-hackers |
On Tue, May 10, 2022 at 09:12:49AM -0700, Nathan Bossart wrote:
> AFAICT you need to set log_min_messages to at least DEBUG3 to see extra
> output for the non-runtime-computed GUCs, so it might not be worth the
> added complexity.
This set of messages is showing up for ages with zero complaints from
the field AFAIK, and nobody would use this level of logging except
developers. One thing that overriding log_min_messages to FATAL does,
however, is to not show anymore those debug3 messages when querying a
runtime-computed GUC, but that's the kind of things we'd hide. Your
patch would hide those entries in both cases. Perhaps we could do
that, but at the end, I don't really see any need to complicate this
code path more than necessary, and this is enough to silence the logs
in the cases we care about basically all the time, even if the log
levels are reduced a bit on a given cluster. Hence, I have applied
the simplest solution to just enforce a log_min_messages=FATAL when
requesting a runtime GUC.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2022-05-11 15:57:19 | Re: Estimating HugePages Requirements? |
| Previous Message | Albin Ary | 2022-05-10 20:58:15 | Re: Tuning Linux for Postgresql - Database failed to start |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-05-11 05:42:26 | Re: Allowing REINDEX to have an optional name |
| Previous Message | Noah Misch | 2022-05-11 05:32:55 | Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set |