On Wed, Apr 13, 2022 at 11:39 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Is there anything else typically done in _PG_init that has to be > conditional on process_shared_preload_libraries_in_progress? I recall > something about reserving LWLocks, which probably should get the same > treatment. If we can get to a point where _PG_init shouldn't need to > care about process_shared_preload_libraries_in_progress, because all > the stuff that would care is moved to this new hook, then that would > be very clear cleanup.
What's a little wonky right now is that it's fairly common for extensions to just return straight-off without doing *anything at all* if !process_shared_preload_libraries_in_progress. See pg_stat_statements for example. It seems kind of strange to me to make registering GUCs dependent on process_shared_preload_libraries_in_progress; why shouldn't that just happen always? It's understandable that we don't want to install the hook functions if we're not being loaded from shared_preload_libaries, though. It may be too much to hope that we're going to completely get rid of process_shared_preload_libraries_in_progress tests. But even given that, I think having a request-shared-mem hook makes sense and would make things cleaner than they are today. Maybe in the future we'll end up with other hooks as well, like a "this is the place to register GUCs" hook and a perhaps a "this is the place to register you custom rmgr" hook. I'm not really sure that we need those and I don't want to make things complicated just for the heck of it, but it's not shocking that different operations need to happen at different times in the startup sequence, and I don't think we should be afraid to split up the monolithic _PG_init() into as many separate things as are required to make it work right. -- Robert Haas EDB: http://www.enterprisedb.com