Re: Estimating HugePages Requirements? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Estimating HugePages Requirements?
Date
Msg-id 20210810034205.r72j5uouynepj4f2@alap3.anarazel.de
Whole thread Raw
In response to Re: Estimating HugePages Requirements?  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: Estimating HugePages Requirements?
List pgsql-hackers
Hi,

On 2021-08-09 22:57:18 +0000, Bossart, Nathan wrote:

> @@ -1026,6 +1031,18 @@ PostmasterMain(int argc, char *argv[])
>       */
>      InitializeMaxBackends();
>  
> +    if (output_shmem)
> +    {
> +        char output[64];
> +        Size size;
> +
> +        size = CreateSharedMemoryAndSemaphores(true);
> +        sprintf(output, "%zu", size);
> +
> +        puts(output);
> +        ExitPostmaster(0);
> +    }

I don't like putting this into PostmasterMain(). Either BootstrapMain()
(specifically checker mode) or GucInfoMain() seem like better places.


> -void
> -CreateSharedMemoryAndSemaphores(void)
> +Size
> +CreateSharedMemoryAndSemaphores(bool size_only)
>  {
>      PGShmemHeader *shim = NULL;
>  
> @@ -161,6 +161,9 @@ CreateSharedMemoryAndSemaphores(void)
>          /* might as well round it off to a multiple of a typical page size */
>          size = add_size(size, 8192 - (size % 8192));
>  
> +        if (size_only)
> +            return size;
> +
>          elog(DEBUG3, "invoking IpcMemoryCreate(size=%zu)", size);
>  
>          /*
> @@ -288,4 +291,6 @@ CreateSharedMemoryAndSemaphores(void)
>       */
>      if (shmem_startup_hook)
>          shmem_startup_hook();
> +
> +    return 0;
>  }

That seems like an ugly API to me. Why don't we split the size
determination and shmem creation functions into two?


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [bug] Logical Decoding of relation rewrite with toast does not reset toast_hash
Next
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Skipping logical replication transactions on subscriber side