Re: Fix possible overflow of pg_stat DSA's refcnt

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

In response to

Responses

Browse pgsql-hackers by date

  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