Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers
Date
Msg-id CAB7nPqT4y8-QoGKEugk99_tFuEOtAshcs5kxOeZ_0w27UtdGyA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers  (Yugo Nagata <nagata@sraoss.co.jp>)
Responses Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers  (Yugo Nagata <nagata@sraoss.co.jp>)
List pgsql-hackers
On Thu, Jun 22, 2017 at 1:52 PM, Yugo Nagata <nagata@sraoss.co.jp> wrote:
> On Thu, 22 Jun 2017 12:05:19 +0900
> Michael Paquier <michael.paquier@gmail.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



pgsql-hackers by date:

Previous
From: Yugo Nagata
Date:
Subject: Re: [HACKERS] Logical replication launcher never been restartedwhen terminated
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] asynchronous execution