Re: Error handling in after-startup shmem requests - Mailing list pgsql-hackers

From Ayush Tiwari
Subject Re: Error handling in after-startup shmem requests
Date
Msg-id CAJTYsWXMcJkcvU9D966AW4PvZoH0649P51yeOM9y-Uo3tsHmag@mail.gmail.com
Whole thread
List pgsql-hackers
Hi,

On Tue, 25 Aug 2026 at 22:17, Heikki Linnakangas <hlinnaka@iki.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

pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: right() returns the whole string for the most negative n
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Assertion failure in GetSubscriptionRelations() with concurrent DROP TABLE