Horton

Re: pgsql: Teach DSM registry to ERROR if attaching to an uninitialized ent

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-11-24T21:02:18Z
Lists: pgsql-hackers 
On Mon, Nov 24, 2025 at 2:03 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
> I think 0002 was more complicated than necessary.  Here's a second try.

I haven't done a full review of this and I'm not sure whether you want
me to spend more time on it, but something I notice about this version
is that the PG_CATCH() blocks only contain dshash_delete_entry()
calls. That seems good, because that means that all the other cleanup
is being handled by transaction abort (assuming that the patch isn't
buggy, which I haven't attempted to verify). However, it does make me
wonder if we could also find a way to postpone adding the dshash
entries so that we don't need to do anything in PG_CATCH() blocks at
all. I'm guessing that the reason why that doesn't easily work is
because you're relying on those locks to prevent multiple backends
from doing the same initialization?

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. Teach DSM registry to retry entry initialization if needed.

  2. Revert "Teach DSM registry to ERROR if attaching to an uninitialized entry."

  3. Teach DSM registry to ERROR if attaching to an uninitialized entry.