Re: Error handling in after-startup shmem requests

Hi,

On Tue, 25 Aug 2026 at 22:17, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:

> On 25/08/2026 19:33, Heikki Linnakangas wrote:
> > Here's my take with some small changes. This is all based on things you
> > already discussed, I just picked the mix I liked best:
>
> And here are the same patches, without the broken comment so that it
> actually compiles... :facepalm:
>

Thanks a lot for the review and patch set.

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?

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?

Regards,
Ayush