Date: Thu, 20 Nov 2025 17:09:31 -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: <aR-fqzfZYSd3TVKa@nathan>
References: <E1vJHUk-006I7r-37@gemulon.postgresql.org>
 <CA+TgmoZGFzLJpYANBG9yDyoakVm-P2Acdker-Y+DHvPWfvBE5w@mail.gmail.com>
 <aR89_9oYFHNtUTFa@nathan>
 <CA+TgmoZCHER55cGmnL_svMjH=k-S0w29ih+ym_+=t032TSsOFA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmoZCHER55cGmnL_svMjH=k-S0w29ih+ym_+=t032TSsOFA@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aR-fqzfZYSd3TVKa%40nathan>
Precedence: bulk

On Thu, Nov 20, 2025 at 01:18:56PM -0500, Robert Haas wrote:
> What I'd be inclined to do after a failure is tear down the entire
> segment. Even if there's no mechanism to retry, you're saving the
> memory that the segment would have consumed.

Unpinning/detaching the segment/DSA/dshash table and deleting the DSM
registry entry in a PG_CATCH block scares me a little, but it might be
doable.

> Or maybe that's all too complicated for too little utility. I'm not sure.

That's ultimately where I landed.

> My perception is that this is setting a significantly lower standard for
> error tolerance than what we typically seek to achieve, but sometimes my
> perceptions are wrong, and sometimes better options are hard to come by.

Another thing that might be subconsciously guiding my decisions here is the
existing behavior when a shmem request/startup hook ERRORs (server startup
fails).  I'd expect DSM registry users to be doing similar things in their
initialization callbacks, and AFAIK this behavior hasn't been a source of
complaints.

-- 
nathan