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
signature.asc
Description: PGP signature
