Message-ID: <261dc9d4-0b87-4e7e-aded-842ed82298e5@iki.fi>
Date: Mon, 6 Apr 2026 15:38:53 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pgsql: Introduce a new mechanism for registering shared memory
 areas
To: Aleksander Alekseev <aleksander@tigerdata.com>,
 pgsql-committers@lists.postgresql.org
References: <E1w9WsZ-00399s-08@gemulon.postgresql.org>
 <CAJ7c6TN9tp8MTc0WXM0zfSWqjfBqU8gpe+o5KqHB1-cQ7409Kw@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: 
 <CAJ7c6TN9tp8MTc0WXM0zfSWqjfBqU8gpe+o5KqHB1-cQ7409Kw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/261dc9d4-0b87-4e7e-aded-842ed82298e5%40iki.fi>
Precedence: bulk

On 06/04/2026 14:55, Aleksander Alekseev wrote:
>> Introduce a new mechanism for registering shared memory areas
>>
>> [...]
> 
> This commit introduced a memory leak which Valgrind is very much upset about.
> 
> ShmemRequestStructWithOpts() allocates a copy of `options` in
> TopMemoryContext and passes it to ShmemRequestInternal(). It appends
> it to pending_shmem_requests as request->options. Later in
> ShmemInitRequested() when the list is freed `->options` leak. There
> are similar issues in ShmemAttachRequested() and
> CallShmemCallbacksAfterStartup() which free pending_shmem_requests
> without freeing `->options`.
> 
> I propose to fix it as attached.

LGTM, I will push this shortly. Thanks!

- Heikki