grOn Mon, Sep 02, 2019 at 12:07:17PM -0400, Tom Lane wrote:
> Euler Taveira <euler@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.
--
