On Tue, Sep 3, 2019 at 11:37 AM Michael Paquier <mich...@paquier.xyz> wrote:
> grOn Mon, Sep 02, 2019 at 12:07:17PM -0400, Tom Lane wrote: > > Euler Taveira <eu...@timbira.com.br> writes: > >> At least if pg_stat_statements > >> was in core you could load it by default and have a GUC to turn it > >> on/off without restarting the server (that was Magnus proposal and > >> Andres agreed). > > > > That assertion is 100% bogus. To turn it on or off on-the-fly, > > you'd need some way to acquire or release its shared memory > > on-the-fly. > > > > It's probably now possible to do something like that, using the > > DSM mechanisms, but the code for it hasn't been written (AFAIK). > > And it wouldn't have much to do with whether the module was > > in core or stayed where it is. > > If we were to actually merge the module into core and switch to DSM > instead of the current fixed amout of shared memory defined at start > time, then that would be a two-step process: first push the functions > into code with a GUC_POSTMASTER as currently done, and secondly > attempt to switch the GUC to be reloadable. > > FWIW, I am not sure that we should have the module into core. > -- > Michael > - It's broadly useful. No doubt it is very useful and most of the customer is using that. - Right now, the barrier for turning it on is quite high. In addition to being non-core, which is already a pretty high barrier at a lot of organizations,it requires a shared_preload_libraries setting, which is pretty close to untenable in a lot of use cases. We are thinking to move a module in core just because of "barrier for turning it on is quite high" which is not a very compelling reason. I am just thinking why not have a system which makes that easy instead of adding to core. -- Ibrar Ahmed
