On Thu, Nov 20, 2025 at 6:09 PM Nathan Bossart <[email protected]> wrote: > 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.
It seems a bit weird to be doing explicit unpinning in a PG_CATCH block. Ideally you'd want to postpone the pinning until initialization has succeeded, so that if you fail before that, transaction cleanup takes care of it automatically. Alternatively, destroying what existed before could be deferred until later, when an as-yet-unfailed transaction stumbles across the tombstone. > 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. What bugs me here is the fact that you have a perfectly good working server that you can't "salvage". If the server had failed at startup, that would have sucked, but you would have been forced into correcting the problem (or giving up on the extension) and restarting, so once the server gets up and running, it's always in a good state. With this mechanism, you can get a running server that's stuck in this failed-initialization state, and there's no way for the DBA to do anything except by bouncing the entire server. That seems like it could be really frustrating. Now, if it's the case that resetting this mechanism wouldn't fundamentally fix anything because the reinitialization attempt would inevitably fail for the same reason, then I suppose it's not so bad, but I'm not sure that would always be true. I just feel like one-way state transitions from good->bad are undesirable. One way of viewing log levels like ERROR, FATAL, and PANIC is that they force you to do a reset of the transaction, session, or entire server to get back to a good state, but here you just get stuck in the bad one. Am I worrying too much? Possibly! But as I said to David on another thread this morning, it's better to worry on pgsql-hackers before any problem happens than to start worrying after something bad happens in a customer situation. -- Robert Haas EDB: http://www.enterprisedb.com
