On Wed, Nov 12, 2025 at 3:31 PM Nathan Bossart <nathan@postgresql.org> wrote:
> Teach DSM registry to ERROR if attaching to an uninitialized entry.
>
> If DSM entry initialization fails, backends could try to use an
> uninitialized DSM segment, DSA, or dshash table (since the entry is
> still added to the registry). To fix, keep track of whether
> initialization completed, and ERROR if a backend tries to attach to
> an uninitialized entry. We could instead retry initialization as
> needed, but that seemed complicated, error prone, and unlikely to
> help most cases. Furthermore, such problems probably indicate a
> coding error.
Having read the thread that led to this commit, I agree that this is
an improvement, but it still doesn't seem like a great situation to
me. Maybe I'm misunderstanding, but it seems like once the
initialization has failed, there's no way to retry: you can't retry
the initialization on the existing segment, and you can't delete it
and create a new segment. If so, that means your only option for
restoring proper function after an initialization failure is to bounce
the entire server.
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.
--
Robert Haas
EDB: http://www.enterprisedb.com
