On Fri, Aug 27, 2021 at 08:16:40PM +0000, Bossart, Nathan wrote: > On 8/27/21, 12:39 PM, "Andres Freund" <and...@anarazel.de> wrote: >> One thing I wonder is if this wouldn't better be dealt with in a more generic >> way. While this is the most problematic runtime computed GUC, it's not the >> only one. What if we introduced a new shared_memory_size GUC, and made >> --describe-config output it? Perhaps adding --describe-config=guc-name? >> >> I also wonder if we should output the number of hugepages needed instead of >> the "raw" bytes of shared memory. The whole business about figuring out the >> huge page size, dividing the shared memory size by that and then rounding up >> could be removed in that case. Due to huge_page_size it's not even >> immediately >> obvious which huge page size one should use... > > I like both of these ideas.
That pretty much looks like -C in concept, isn't it? Except that you cannot get the actual total shared memory value because we'd do this operation before loading shared_preload_libraries and miss any amount asked by extensions. There is a problem similar when attempting to do postgres -C data_checksums, for example, which would output an incorrect value even if the cluster has data checksums enabled. -- Michael
signature.asc
Description: PGP signature
