Re: Estimating HugePages Requirements?
От | Nathan Bossart |
---|---|
Тема | Re: Estimating HugePages Requirements? |
Дата | |
Msg-id | 20220314173417.GA1020555@nathanxps13 обсуждение исходный текст |
Ответ на | Re: Estimating HugePages Requirements? (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Estimating HugePages Requirements?
|
Список | pgsql-hackers |
On Mon, Mar 14, 2022 at 04:26:43PM +0100, Magnus Hagander wrote: > Nothing fixing this ended up actually getting committed, right? That > is, we still get the extra log output? Correct. > And in fact, the command documented on > https://www.postgresql.org/docs/devel/kernel-resources.html doesn't > actually produce the output that the docs show, it also shows the log > line, in the default config? If we can't fix the extra logging we > should at least have our docs represent reality -- maybe by adding a > "2>/dev/null" entry? But it'd be better to have it not output that log > in the first place... I attached a patch to adjust the documentation for now. This apparently crossed my mind earlier [0], but I didn't follow through with it for some reason. > (Of course what I'd really want is to be able to run it on a cluster > that's running, but that was discussed downthread so I'm not bringing > that one up for changes now) I think it is worth revisiting the extra logging and the ability to view runtime-computed GUCs on a running server. Should this be an open item for v15, or do you think it's alright to leave it for the v16 development cycle? [0] https://postgr.es/m/C45224E1-29C8-414C-A8E6-B718C07ACB94%40amazon.com -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: