From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, "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>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Estimating HugePages Requirements? |
Date: | 2022-03-15 22:44:39 |
Message-ID: | 20220315224439.GA1133771@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers |
On Tue, Mar 15, 2022 at 11:02:37PM +0100, Magnus Hagander wrote:
> I think we're talking about two different things here.
>
> I think the "avoid extra logging" would be worth seeing if we can
> address for 15.
A simple approach could be to just set log_min_messages to PANIC before
exiting. I've attached a patch for this. With this patch, we'll still see
a FATAL if we try to use 'postgres -C' for a runtime-computed GUC on a
running server, and there will be no extra output as long as the user sets
log_min_messages to INFO or higher (i.e., not a DEBUG* value). For
comparison, 'postgres -C' for a non-runtime-computed GUC does not emit
extra output as long as the user sets log_min_messages to DEBUG2 or higher.
> The "able to run on a live cluster" seems a lot bigger and more scary
> and not 15 material.
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Attachment | Content-Type | Size |
---|---|---|
v2-0001-don-t-emit-shutdown-messages-for-postgres-C-with-.patch | text/x-diff | 841 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Shaozhong SHI | 2022-03-16 20:14:43 | Apparently table locks are the key issue to see red flags |
Previous Message | Magnus Hagander | 2022-03-15 22:02:37 | Re: Estimating HugePages Requirements? |
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2022-03-15 22:57:48 | Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths |
Previous Message | Yura Sokolov | 2022-03-15 22:13:09 | Re: BufferAlloc: don't take two simultaneous locks |