On Fri, Jan 16, 2026 at 12:31 AM Zsolt Parragi <[email protected]> wrote: > Yes, I see that concern, but that's a bit trickier. To do that > properly we have to validate the variables, including their values, > not just their names. If we only validate the names, that doesn't > guarantee anything.
Right. This goes back to your question upthread as to why I brought session_preload_libraries into all this -- I thought session_preload_libraries already had handling for this, but it doesn't. > Would it be a good idea for it to dlopen/dlclose libraries? No, unfortunately. > The > requirements of dlclose are not that strict, I'm not sure if it could > cause any issues. Last I knew (which was a while back), unloading a shared library tree is fraught with peril, especially when you add dependency diamonds and static initializers. I seem to remember that Windows, C++, and OpenSSL all have particular areas of pain. My guess is that people are going to make mistakes, leave dangling references around, and then either crash the postmaster or (worse) copy a crashable address space into every new backend. And that's before you get into hooks and GUCs and etc. We used to have a _PG_fini() callback for modules. It was disabled a long time ago [1], then recently entirely removed from the codebase. > > I might be misunderstanding, but wouldn't that imply that DBAs could > > now put every existing SIGHUP setting into HBA? That doesn't seem > > good. > > Yes, that would mean that. I'm not saying that would be > better/semantically correct, but technically it could also work, > that's why I mentioned it. Okay, but that wouldn't be a committable change. > The main use of PGC_HBA in this patch is to > add additional error reporting / separate what can be placed into > pg_hba. I could argue both for this approach and the opposite where we > allow other variables in pg_hba. Not sure what you mean by this (maybe once I can really test the patch, I'll see?), but the reason I suggested placing PGC_HBA right after PGC_SIGHUP is this: any SU_BACKEND or below variable seems logically appropriate to set per HBA line, if the DBA wants (they're all per-session), and anything SIGHUP or above is inappropriate/unsafe (they're per-cluster). Does your patch disable the former? [checks] Ah, it does prohibit those. Why? --Jacob [1] https://postgr.es/c/602a9ef5a7c60151e10293ae3c4bb3fbb0132d03
