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
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 |