From: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: problems with "Shared Memory and Semaphores" section of docs |
Date: | 2024-05-17 18:30:08 |
Message-ID: | B22D8E61-490D-4B89-9C62-41C36098011F@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Borisov | 2024-05-17 18:51:38 | Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index. |
Previous Message | Tom Lane | 2024-05-17 18:11:54 | Re: Postgres and --config-file option |