Re: problems with "Shared Memory and Semaphores" section of docs
От | Imseih (AWS), Sami |
---|---|
Тема | Re: problems with "Shared Memory and Semaphores" section of docs |
Дата | |
Msg-id | B22D8E61-490D-4B89-9C62-41C36098011F@amazon.com обсуждение исходный текст |
Ответ на | Re: problems with "Shared Memory and Semaphores" section of docs (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: problems with "Shared Memory and Semaphores" section of docs
Re: problems with "Shared Memory and Semaphores" section of docs |
Список | pgsql-hackers |
>>> If the exact values >>> are important, maybe we could introduce more GUCs like >>> shared_memory_size_in_huge_pages that can be consulted (instead of >>> requiring users to break out their calculators). >> >> I don't especially like shared_memory_size_in_huge_pages, and I don't >> want to introduce more of those. GUCs are not the right way to expose >> values that you can't actually set. (Yeah, I'm guilty of some of the >> existing ones like that, but it's still not a good thing.) Maybe it's >> time to introduce a system view for such things? It could be really >> simple, with name and value, or we could try to steal some additional >> ideas such as units from pg_settings. I always found some of the preset GUCs [1] to be useful for writing SQLs used by DBAs, particularly block_size, wal_block_size, server_version and server_version_num. > The advantage of the GUC is that its value could be seen before trying to > actually start the server. Only if they have a sample in postgresql.conf file, right? A GUC like shared_memory_size_in_huge_pages will not be. [1] https://www.postgresql.org/docs/current/runtime-config-preset.html Regards, Sami
В списке pgsql-hackers по дате отправления: