Re: Improve logging when using Huge Pages
От | Justin Pryzby |
---|---|
Тема | Re: Improve logging when using Huge Pages |
Дата | |
Msg-id | 20230124012100.GB13860@telsasoft.com обсуждение исходный текст |
Ответ на | Re: Improve logging when using Huge Pages (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Improve logging when using Huge Pages
|
Список | pgsql-hackers |
On Wed, Nov 09, 2022 at 02:04:00PM +0900, Michael Paquier wrote: > On Wed, Nov 09, 2022 at 11:47:57AM +0900, Kyotaro Horiguchi wrote: > > Honestly I don't come up with other users of the new > > log-level. Another possible issue is it might be a bit hard for people > > to connect that level to huge_pages=try, whereas I think we shouldn't > > put a description about the concrete impact range of that log-level. > > > > I came up with an alternative idea that add a new huge_pages value > > try_report or try_verbose, which tell postgresql to *always* report > > the result of huge_pages = try. > > Here is an extra idea for the bucket of ideas: switch the user-visible > value of huge_pages to 'on' when we are at "try" but success in using > huge pages, and switch the visible value to "off". The idea of Justin > in [1] to use an internal runtime-computed GUC sounds sensible, as well > (say a boolean effective_huge_pages?). > > [1]: https://www.postgresql.org/message-id/20221106130426.GG16921@telsasoft.com > -- > Michael Michael seemed to support this idea and nobody verbalized hatred of it, so I implemented it. In v15, we have shared_memory_size_in_huge_pages, so this adds effective_huge_pages. Feel free to suggest a better name. -- Justin
Вложения
В списке pgsql-hackers по дате отправления: