From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, 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-23 20:07:01 |
Message-ID: | 20170623200701.erac2hona6rwbbz7@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-06-23 20:10:35 | Re: Logical replication: stuck spinlock at ReplicationSlotRelease |
Previous Message | Tom Lane | 2017-06-23 20:04:48 | Re: Same expression more than once in partition key |