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

From Alvaro Herrera
Subject Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers
Date
Msg-id 20170623200701.erac2hona6rwbbz7@alvherre.pgsql
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  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Yugo Nagata wrote:

> I tried to make it. Patch attached. 
> 
> It is easy and simple. Although I haven't tried for autovacuum worker,
> I confirmed I can change other process' parameters without affecting others.
> Do you want this in PG?

One advantage of this gadget is that you can signal backends that you
own without being superuser, so +1 for the general idea.  (Please do
create a fresh thread so that this can be appropriately linked to in
commitfest app, though.)

You need a much bigger patch for the autovacuum worker.  The use case I
had in mind is that you have a maintenance window and can run fast
vacuuming during it, but if the table is large and vacuum can't finish
within that window then you want vacuum to slow down, without stopping
it completely.  But implementing this requires juggling the
stdVacuumCostDelay/Limit values during the reload, which are currently
read at start of vacuuming only; the working values are overwritten from
those during a rebalance.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Same expression more than once in partition key
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Logical replication: stuck spinlock atReplicationSlotRelease