On Tue, Nov 2, 2021 at 12:39 PM Bossart, Nathan <bossa...@amazon.com> wrote:> > On 11/2/21, 9:17 AM, "Robert Haas" <robertmh...@gmail.com> wrote: > You could still introduce GUCs in _PG_init(), but they couldn't be > defined as PGC_POSTMASTER.
It seems like PGC_POSTMASTER isn't very desirable anyway. Wouldn't you want PGC_SIGHUP? I mean I'm not saying there couldn't be a case where that wouldn't work, because you could need a big chunk of shared memory allocated at startup time or something. But in that's probably not typical, and if it does happen well then that particular archive module has to be preloaded. If you know that you have several archive modules that you want to use, you can still preload them all if for this or any other reason you want to do that. But in a lot of cases it's not going to be necessary. In other words, if we use hooks, then you're guaranteed to need a server restart to change anything. If we use something like what you have now, there can be corner cases where you need that or benefits of preloading, but it's not a hard requirement, and in many cases you can get by without it. That seems strictly better to me ... but maybe I'm still confused. > Also, you could still use > RegisterDynamicBackgroundWorker() to register a background worker, but > you couldn't use RegisterBackgroundWorker(). These might be > acceptable restrictions if swapping archive libraries on the fly seems > more important, but I wanted to bring that front and center to make > sure everyone understands the tradeoffs. RegisterDynamicBackgroundWorker() seems way better, though. It's hard for me to understand why this would be a problem for anybody. And again, if somebody does have that need, they can always fall back to saying that their particular module should be preloaded if you want to use it. -- Robert Haas EDB: http://www.enterprisedb.com
