From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fix possible overflow of pg_stat DSA's refcnt |
Date: | 2024-06-26 05:39:57 |
Message-ID: | ZnuprZeVZd2X_MOD@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Sharma | 2024-06-26 05:49:12 | Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions |
Previous Message | Andy Fan | 2024-06-26 05:39:06 | Re: cost delay brainstorming |