Re: [HACKERS] [PATCH] pg_reload_backend to signal SIGHUP to aspecific backend

Поиск
Список
Период
Сортировка
От Remi Colinet
Тема Re: [HACKERS] [PATCH] pg_reload_backend to signal SIGHUP to aspecific backend
Дата
Msg-id CADdR5nwj-DqXxviEMtxsSNTSjZ=FRFU8tD67Vqb8HTEeBB6Rvw@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] [PATCH] pg_reload_backend to signal SIGHUP to a specific backend  (Yugo Nagata <nagata@sraoss.co.jp>)
Ответы Re: [HACKERS] [PATCH] pg_reload_backend to signal SIGHUP to aspecific backend  (Yugo Nagata <nagata@sraoss.co.jp>)
Список pgsql-hackers
Hi Yugo,

The patch looks fine. Installed and tested.

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.

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


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

Предыдущее
От: Zero King
Дата:
Сообщение: [HACKERS] [PATCH] doc: Fix typo
Следующее
От: Lelisa Diriba
Дата:
Сообщение: [HACKERS] building Postgresql-9.0.10 with patching MERGE keyword