On Thu, Nov 20, 2025 at 10:44:31AM -0500, Robert Haas wrote: > Now, perhaps the chances of an initialization failure in practice are > quite low. Maybe a typical initialization function won't do anything > that could fail. But it just seems weird to me to design something > that thinks errors are likely enough that it's worth having some > amount of mechanism to deal with them, but unlikely enough that it's > not worth making that mechanism more robust.
Well, I will attempt to convince you that is indeed the case, although I'm not sure I will succeed... ISTM that besides pure coding errors, the most likely reasons for an ERROR during DSM segment initialization are things like out-of-memory, too many LWLock tranches registered, etc. In those cases, do we want every single backend that tries to attach to the segment to retry and most likely fail again? And what if the initialization callback completed halfway before failing? Do we expect every extension author to carefully craft their callbacks to handle that? On the other hand, if we don't handle ERRORs and someone does run into an OOM or whatnot, do we want other backends to attach and use the unitialized segment (leading to things like seg-faults)? Tracking whether an entry was initialized seems like cheap insurance against these problems. Finally, the only report from the field about any of this involves SQLsmith allocating tons of LWLock tranches via test_dsa, which has been fixed independently. So I have no evidence to suggest that we need to make it more robust. In fact, without this one arguably contrived report, I probably wouldn't have done anything at all. I'll grant you that this is a judgment call. I tried to find a good middle ground, but I would be unsurprised to learn that other committers would have done things differently. -- nathan
