Re: Error handling in after-startup shmem requests

On 26/08/2026 08:59, Ayush Tiwari wrote:
> This approach looks good to me overall.  I built the v2 series with
> assertions and injection points enabled, and all five tests passed.
>
> I had one question about the lifetime of the options copy.  It is still
> allocated in TopMemoryContext, while the after-startup path no longer calls
> pfree(request->options).  The PG_FINALLY block clears
> pending_shmem_requests, but could that leave the options allocated until
> backend exit?  The impact seems small, but perhaps the options should be
> freed before clearing the list, or allocated in the same context as the
> requests?

You're right. I changed it to use TopMemoryContext like you had it
originally. That seems more clear, after all.

> One minor test nit:
>
> - The comment says "A failure in the requesting shared memory", but the
>   injection point triggers in test_shmem_init(), so would "initializing
>   shared memory" be more accurate?

Yeah. I did some other cleanups in the test too, and merged the tests
into the commits with the code fixes. Here's a new version, if you want
to have one final look.

- Heikki