Re: [HACKERS] [PATCH] pg_reload_backend to signal SIGHUP to aspecific backend
От | Yugo Nagata |
---|---|
Тема | Re: [HACKERS] [PATCH] pg_reload_backend to signal SIGHUP to aspecific backend |
Дата | |
Msg-id | 20170629154920.f1df919e.nagata@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] pg_reload_backend to signal SIGHUP to aspecific backend (Remi Colinet <remi.colinet@gmail.com>) |
Список | pgsql-hackers |
On Wed, 28 Jun 2017 13:59:51 +0200 Remi Colinet <remi.colinet@gmail.com> wrote: > Hi Yugo, > > The patch looks fine. Installed and tested. Thank you for your interest. > > But a similar function already exists for the Postmaster process. > > Datum > pg_reload_conf(PG_FUNCTION_ARGS) > { > if (kill(PostmasterPid, SIGHUP)) > { > ereport(WARNING, > (errmsg("failed to send signal to > postmaster: %m"))); > PG_RETURN_BOOL(false); > } > > PG_RETURN_BOOL(true); > } > > I would suggest to merge your patch with above function which is close to > yours. > Btw, your patch looks better that above function code. > > You may for instance retain pg_reload_conf() without argument for the same > purpose as currently (Postmaster signaling). > And provide a pid argument to signal a given backend. Actually, I proposed that version patch in the previous thread[1], but there as a suggestion to use other function name, so I attached fixed version in this thread. [1] https://www.postgresql.org/message-id/20170624000156.74ca9485.nagata%40sraoss.co.jp > > Regards > Remi > > > 2017-06-28 12:17 GMT+02:00 Yugo Nagata <nagata@sraoss.co.jp>: > > > Hi, > > > > Attached is a patch of pg_reload_backend that is a function signaling > > SIGHUP to a specific backend. The original idea is from Michael Paquier[1]. > > The documatation isn't included in this patch yet. > > > > We can change some parameters of other backend using the function > > as bellow. > > > > postgres=# alter system set log_min_messages to debug2; > > ALTER SYSTEM > > postgres=# select pg_reload_backend(18375); > > pg_reload_backend > > ------------------- > > t > > (1 row) > > > > There are some usecases. For example: > > > > - changing log configuration in other backends temporally. > > - changing cost parameters for planner in other backends. > > - changing autovacuum parameters of an already running autovacuum worker. > > > > > > Hoever, this function need the superuser previlige to execute as well as > > pg_reload_conf(). Although we can grant the execution to public, it is > > useless for normal users bacause only superuser can change postgresql.conf. > > > > To allow normal users to change parameters in ohter backends, instead > > we might want another feature, for example, a function like set_config() > > than can change other backend's parameters using shared memory and SIGUSR1. > > > > Any comments would be appreciated. > > > > Regards, > > > > [1] > > https://www.postgresql.org/message-id/CAB7nPqT4y8- > > QoGKEugk99_tFuEOtAshcs5kxOeZ_0w27UtdGyA%40mail.gmail.com > > > > -- > > Yugo Nagata <nagata@sraoss.co.jp> > > > > > > -- > > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > > To make changes to your subscription: > > http://www.postgresql.org/mailpref/pgsql-hackers > > > > -- Yugo Nagata <nagata@sraoss.co.jp>
В списке pgsql-hackers по дате отправления: