Re: [PATCH] pg_reload_backend to signal SIGHUP to a specific backend

From: Remi Colinet <remi(dot)colinet(at)gmail(dot)com>
To: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] pg_reload_backend to signal SIGHUP to a specific backend
Date: 2017-06-28 11:59:51
Message-ID: CADdR5nwj-DqXxviEMtxsSNTSjZ=FRFU8tD67Vqb8HTEeBB6Rvw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sraoss(dot)co(dot)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(at)sraoss(dot)co(dot)jp>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lelisa Diriba 2017-06-28 12:06:13 building Postgresql-9.0.10 with patching MERGE keyword
Previous Message Zero King 2017-06-28 11:54:48 [PATCH] doc: Fix typo