Re: Estimating HugePages Requirements?

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Estimating HugePages Requirements?
Дата
Msg-id YTq82THcfR0jnqDw@paquier.xyz
обсуждение исходный текст
Ответ на Re: Estimating HugePages Requirements?  ("Bossart, Nathan" <bossartn@amazon.com>)
Ответы Re: Estimating HugePages Requirements?  ("Bossart, Nathan" <bossartn@amazon.com>)
Список pgsql-hackers
On Thu, Sep 09, 2021 at 09:53:22PM +0000, Bossart, Nathan wrote:
> For 0002, I have two small concerns.  My first concern is that it
> might be confusing to customers when the runtime GUCs cannot be
> returned for a running server.  We have the note in the docs, but if
> you're encountering it on the command line, it's not totally clear
> what the problem is.

Yeah, that's true.  There are more unlikely-to-happen errors that
could be triggered and prevent the command to work.  I have never
tried using error_context_stack in a code path as early as that, to be
honest.

> Running these commands with log_min_messages=debug5 emits way more
> information for the runtime-computed GUCs than for others, but IMO
> that is alright.  However, perhaps we should adjust the logging in
> 0002 to improve the default user experience.  I attached an attempt at
> that.

Registered bgworkers would generate a DEBUG entry, for one.

> I'm not tremendously happy with the patch, but I hope that it at least
> helps with the discussion.

As far as the behavior is documented, I'd be fine with the approach to
keep the code in its simplest shape.  I agree that the message is
confusing, still it is not wrong either as we try to query a run-time
parameter, but we need the lock.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_walinspect - a new extension to get raw WAL data and WAL stats
Следующее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: Estimating HugePages Requirements?