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?
|
Список | 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 по дате отправления: