Date: Thu, 20 Nov 2025 10:12:47 -0600
From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Nathan Bossart <nathan@postgresql.org>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pgsql: Teach DSM registry to ERROR if attaching to an
 uninitialized ent
Message-ID: <aR89_9oYFHNtUTFa@nathan>
References: <E1vJHUk-006I7r-37@gemulon.postgresql.org>
 <CA+TgmoZGFzLJpYANBG9yDyoakVm-P2Acdker-Y+DHvPWfvBE5w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmoZGFzLJpYANBG9yDyoakVm-P2Acdker-Y+DHvPWfvBE5w@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aR89_9oYFHNtUTFa%40nathan>
Precedence: bulk

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