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

From Stephen Frost
Subject Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers
Date
Msg-id 20170623234335.GF1769@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers
List pgsql-hackers
Alvaro, all,

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> 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.)

Well, that wouldn't quite work with the proposed patch because the
proposed patch REVOKE's execute from public...

I'm trying to figure out how it's actually useful to be able to signal a
backend that you own about a config change that you *aren't* able to
make without being a superuser..  Now, if you could tell the other
backend to use a new value for some USERSET GUC, then *that* would be
useful and interesting.

I haven't got any particularly great ideas for how to make that happen
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.

Being able to change those values during a vacuuming run would certainly
be useful, I've had cases where I would have liked to have been able to
do just exactly that.  That's largely independent of this though.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Logical replication: stuck spinlock atReplicationSlotRelease
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Logical replication: stuck spinlock atReplicationSlotRelease