Re: pgsql: Teach DSM registry to ERROR if attaching to an uninitialized ent
Nathan Bossart <nathandbossart@gmail.com>
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>
Date: 2025-11-20T23:09:31Z
Lists: 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
Commits
-
Teach DSM registry to retry entry initialization if needed.
- dbdc717ac674 19 (unreleased) landed
- b83bcc0df180 18.2 landed
- 2fc5c5062207 17.8 landed
-
Revert "Teach DSM registry to ERROR if attaching to an uninitialized entry."
- c7e0f263d67f 17.8 landed
- 8551a289201c 18.2 landed
- 2dd506b859cf 19 (unreleased) landed
-
Teach DSM registry to ERROR if attaching to an uninitialized entry.
- 1165a933aab1 19 (unreleased) cited