Re: pgsql: Teach DSM registry to ERROR if attaching to an uninitialized ent - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: pgsql: Teach DSM registry to ERROR if attaching to an uninitialized ent
Date
Msg-id aR-fqzfZYSd3TVKa@nathan
Whole thread Raw
In response to Re: pgsql: Teach DSM registry to ERROR if attaching to an uninitialized ent  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Extended Statistics set/restore/clear functions.
Next
From: Masahiko Sawada
Date:
Subject: Re: Add support for COPY TO in tablesync for partitioned tables.