Re: 回复: Fix segfault while accessing half-initialized hash table in pgstat_shmem.c - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: 回复: Fix segfault while accessing half-initialized hash table in pgstat_shmem.c
Date
Msg-id aLgNuGcQ8NAANUp7@paquier.xyz
Whole thread Raw
In response to 回复: Fix segfault while accessing half-initialized hash table in pgstat_shmem.c  (Steven Niu <niushiji@gmail.com>)
Responses 回复: 回复: Fix segfault while accessing half-initialized hash table in pgstat_shmem.c
List pgsql-hackers
On Wed, Sep 03, 2025 at 07:22:00AM +0000, Steven Niu wrote:
> So unless dsa_allocate() can ensure never returns InvalidDsaPointer,
> there is risk of SegV.  In fact the function dsa_allocate() does
> return InvalidDsaPointer in some cases.
>
> So, maybe should we add pointer check in all places where dsa_get_address is called. Comments?

dsa_allocate() calls dsa_allocate_extended() without DSA_ALLOC_NO_OOM,
hence on allocation failure the code does a ereport(ERROR).  It would
be a problem to not check the result if DSA_ALLOC_NO_OOM is used.

The problem dealt with here is different, as far as I understand: we
set some data in shared memory without considering that the DSA
allocation could fail, leaving shared memory in an inconsistent state
when an allocation failure occurs.  The problem is not in the
allocation failure in itself, but in the dependency that we have
between the state in shared memory and the allocation attempt for this
pgstats code path.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Generate GUC tables from .dat file
Next
From: Antonin Houska
Date:
Subject: Unexpected changes of CurrentResourceOwner and CurrentMemoryContext