Re: Fix possible overflow of pg_stat DSA's refcnt - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Fix possible overflow of pg_stat DSA's refcnt
Date
Msg-id ZnuprZeVZd2X_MOD@paquier.xyz
Whole thread Raw
In response to Fix possible overflow of pg_stat DSA's refcnt  (Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>)
Responses Re: Fix possible overflow of pg_stat DSA's refcnt
List pgsql-hackers
On Tue, Jun 25, 2024 at 05:01:55PM +0200, Anthonin Bonnefoy wrote:
> During backend initialisation, pgStat DSA is attached using
> dsa_attach_in_place with a NULL segment. The NULL segment means that
> there's no callback to release the DSA when the process exits.
> pgstat_detach_shmem only calls dsa_detach which, as mentioned in the
> function's comment, doesn't include releasing and doesn't decrement the
> reference count of pgStat DSA.
>
> Thus, every time a backend is created, pgStat DSA's refcnt is incremented
> but never decremented when the backend shutdown. It will eventually
> overflow and reach 0, triggering the "could not attach to dynamic shared
> area" error on all newly created backends. When this state is reached, the
> only way to recover is to restart the db to reset the counter.

Very good catch!  It looks like you have seen that in the field, then.
Sad face.

> This patch fixes this issue by releasing pgStat DSA with
> dsa_release_in_place during pgStat shutdown to correctly decrement the
> refcnt.

Sounds logic to me to do that in the pgstat shutdown callback, ordered
with the dsa_detach calls in a single location rather than registering
a different callback to do the same job.  Will fix and backpatch,
thanks for the report!
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: cost delay brainstorming
Next
From: Ashutosh Sharma
Date:
Subject: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions