|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Euler Taveira <euler(at)timbira(dot)com(dot)br>, Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Proposal: roll pg_stat_statements into core|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
grOn Mon, Sep 02, 2019 at 12:07:17PM -0400, Tom Lane wrote:
> Euler Taveira <euler(at)timbira(dot)com(dot)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
> 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.
|Next Message||Peter Eisentraut||2019-09-03 06:38:22||Re: fix "Success" error messages|
|Previous Message||Michael Paquier||2019-09-03 06:30:24||Re: Contribution to Perldoc for TestLib module in Postgres|