Re: pg_terminate_backend can terminate background workers and autovacuum launchers

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_terminate_backend can terminate background workers and autovacuum launchers
Date: 2017-06-22 05:08:30
Message-ID: CAB7nPqT4y8-QoGKEugk99_tFuEOtAshcs5kxOeZ_0w27UtdGyA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 22, 2017 at 1:52 PM, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> wrote:
> On Thu, 22 Jun 2017 12:05:19 +0900
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
>> signal-able). Different thought, but I'd love to see a SQL function
>> that allows triggering SIGHUP on a specific process, like an
>> autovacuum worker to change its cost parameters. There is
>> pg_reload_conf() to do so but that's system-wide.
>
> For example, is that like this?
>
> =# alter system set autovacuum_vacuum_cost_delay to 10;
> =# select pg_reload_conf(<PID of autovacuum worker)>);
> =# alter system reset autovacuum_vacuum_cost_delay;

No need to reset the parameter afterwards as this makes it sensible to
updates afterwards, but you have the idea. Note that this is rather
recent, as autovacuum listens to SIGHUP only since a75fb9b3.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2017-06-22 05:17:20 Re: asynchronous execution
Previous Message Yugo Nagata 2017-06-22 05:06:24 Re: Logical replication launcher never been restarted when terminated