Re: Proposal: roll pg_stat_statements into core

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Proposal: roll pg_stat_statements into core
Дата
Msg-id 20190903063727.GG3765@paquier.xyz
обсуждение исходный текст
Ответ на Re: Proposal: roll pg_stat_statements into core  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Proposal: roll pg_stat_statements into core  (Ibrar Ahmed <ibrar.ahmad@gmail.com>)
Список pgsql-hackers
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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Contribution to Perldoc for TestLib module in Postgres
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: fix "Success" error messages