Re: PostgreSQL 18.4 backend SIGSEGV in pgstat_gc_entry_refs() after caught DSM attach error

On Fri, Aug 07, 2026 at 03:34:38PM +0900, Michael Paquier wrote:
> 5) While on it, I think that we could do something about the
> dshash_find_or_insert() in pgstat_get_entry_ref(), where we could
> clean up the local reference if dshash_find_or_insert() returns NULL.
> That's content only worth on HEAD, as the problem is unlikely going to
> happen in practice, and that's only a local reference.
>
> To summarize, I have fixed 2) with 4069df21beb8 backpatched down to
> v15, and did bf80a4c2d238 for 1) on HEAD. 3) is not necessary. 4)
> should have its own discussion, as it's a broader change impacting
> anything that uses DSA/DSM. And I am planning to apply the attached
> for 5) only on HEAD as a follow-up improvement.

A consequence of 5) that I have missed during my initial lookup is
that it could be possible to finish with a NULL pointer dereference if
a concurrent backend has the idea to bump the refcount of the entry
that has a stale NULL shared_entry (due to entry reinit, for one, or
even a drop/create). A OOM-ed backend calling pgstat_gc_entry_refs()
would be in trouble.

It's the first time I've heard about dshash_find_or_insert_extended().
That's kind of nice, perhaps it would make sense to extend its use in
other areas of the code..
--
Michael