Message-ID: <1494c82a-6f8a-449d-a90b-cd96d9b47be5@iki.fi>
Date: Sun, 5 Apr 2026 19:13:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Better shared data structure management and resizable shared data
 structures
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Robert Haas <robertmhaas@gmail.com>,
 Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
 Andres Freund <andres@anarazel.de>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
 chaturvedipalak1911@gmail.com
References: 
 <CAExHW5vM1bneLYfg0wGeAa=52UiJ3z4vKd3AJ72X8Fw6k3KKrg@mail.gmail.com>
 <CAExHW5so6VSxBC-1V=35229Z1+dw5vhw8HxHg9ry7UzceKcXzA@mail.gmail.com>
 <26c766d6-db0f-43d3-a618-44f8d40a3121@iki.fi>
 <CA+TgmoaoSha9KnSdrA7DDMYD9+Uor4OPEaQ88bbEC3QuVE5Mcg@mail.gmail.com>
 <62b8dc23-8f6a-4cac-91ff-f74bb5bc159a@iki.fi>
 <CA+TgmoboxAaS6MCRf__LRhf8Ji3B0O9_=d7KzRS12QhOuocnTQ@mail.gmail.com>
 <c7b4dafc-7a6c-43e4-8b9e-20807396590b@iki.fi>
 <CA+Tgmob7E3CGDoEBB3mwfk+v1CgcOG8yL0VHje2gy9Ts=e1Zxw@mail.gmail.com>
 <f8fc6f77-292d-4225-9f54-382c39da5ebc@iki.fi>
 <CA+TgmobqwCHp1w6xkTJmZiq4C8Pr0O3tNUvSFZcAgYLkvF45bg@mail.gmail.com>
 <8a6799be-bd42-49fb-8914-856c97bb1977@iki.fi>
 <CA+Tgmob8ot7qam7a650nx_4jyEoFLs8s_kPMc1+EB7-dr56=WA@mail.gmail.com>
 <cc3ff976-c303-45cd-9a8d-a90483170e37@iki.fi>
 <CA+TgmoauqYXm8iA3FGRAVKxYShUxWBiS_MSLmQpTrmO7wNHamw@mail.gmail.com>
 <113724ab-0028-493f-9605-6e8570f0939f@iki.fi>
 <92C8000B-4EE3-44FC-ABDD-6081E0B46D17@yesql.se>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <92C8000B-4EE3-44FC-ABDD-6081E0B46D17@yesql.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/1494c82a-6f8a-449d-a90b-cd96d9b47be5%40iki.fi>
Precedence: bulk

On 26/03/2026 20:31, Daniel Gustafsson wrote:
>> On 22 Mar 2026, at 01:14, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> * The request_fn callback is called in postmaster startup, at the same stage as the old shmem_request callback was. But in EXEC_BACKEND mode, it's *also* called in each backend.
> 
> Should the request_fn be told, via an argument, from where it is called?  It
> can be figured out but it's cleaner if all implementations will do it in the
> same way.  I don't have a direct case in mind where it would be needed, but I
> was recently digging into SSL passphrase reloading which has failure cases
> precisely becasue of this so am thinking out loud to avoid similar problems
> here.

Hmm, you mean adding an argument along the lines of:

static void
pgss_shmem_request(void *arg, bool attaching)
{
     ...
}

Perhaps. The idea is that a request callback should generally do the 
exact same thing whether it's called from postmaster or from backend 
startup, though. I worry that an argument like that makes it too 
tempting to have different logic. That said, there are a couple of 
places where I'm using IsUnderPostmaster for that purpose. For example, 
I have this in lwlock.c (in latest version I'm currently working on that 
I haven't posted yet):

/* Size of MainLWLockArray.  Only valid in postmaster. */
static int	num_main_array_locks;

/*
  * Request shmem space for user-defined tranches and the main LWLock array.
  */
static void
LWLockShmemRequest(void *arg)
{
     size_t        size;

     /* Space for user-defined tranches */
     ShmemRequestStruct(.name = "LWLock tranches",
                        .size = sizeof(LWLockTrancheShmemData),
                        .ptr = (void **) &LWLockTranches,
         );

     /* Space for the LWLock array */
     if (!IsUnderPostmaster)
     {
         num_main_array_locks = NUM_FIXED_LWLOCKS + 
NumLWLocksForNamedTranches();
         size = num_main_array_locks * sizeof(LWLockPadded);
     }
     else
         size = SHMEM_ATTACH_UNKNOWN_SIZE;

     ShmemRequestStruct(.name = "Main LWLock array",
                        .size = size,
                        .ptr = (void **) &MainLWLockArray,
         );
}

- Heikki