Re: DSA_ALLOC_NO_OOM vs dsm_create ERROR leaving a half-initialized pgstats hash entry

On Tue, Sep 08, 2026 at 09:06:36AM +0000, Grigorev Jurij wrote:
> I would rather not go back to PG_TRY/PG_CATCH around
> pgstat_init_entry(); that was considered in [2] and dropped in favour
> of returning NULL.

I've never been much on favor of TRY/CATCH generally for any kind of
low-level subsystem because it makes the stack manipulations more
complicated, sometimes with static states that need to be kept at
backend level (think threading). Being able to keep track of the
state across

> Option (1) could close the pgstats corruption independently of the
> lower-level question. Option (2) would make the NO_OOM behavior
> consistent for other callers as well.
>
> I can prepare the pgstats patch for (1), or investigate the DSA/DSM
> approach first if you think that is the better layer. I can also add a
> deterministic failure-injection test for the new-segment path.

My question regarding (1) vs (2) would be: do we have other
sub-systems that display patterns similar to pgstats when it comes to
the DSA/DSM failing? If pgstats is the only one, (1) sounds like a
solution good enough for me. (2) would show more value if there is a
gazillion of call sites that would like to care about more error
states when doing a DSA/DSM allocation.

I'd still tend to prefer (1) compared to (2) on top of my mind, but
I'm proved wrong a lot, so..
--
Michael