Re: pg_terminate_backend can terminate background workers and autovacuum launchers

On Sat, 24 Jun 2017 08:09:52 +0900
Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:

> On Sat, Jun 24, 2017 at 5:07 AM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)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?
>
> Just browsing the patch...
>
> + if (r == SIGNAL_BACKEND_NOSUPERUSER)
> + ereport(WARNING,
> + (errmsg("must be a superuser to terminate superuser
> process")));
> +
> + if (r == SIGNAL_BACKEND_NOPERMISSION)
> + ereport(WARNING,
> + (errmsg("must be a member of the role whose process
> is being terminated or member of pg_signal_backend")));
> Both messages are incorrect. This is not trying to terminate a process.

I'll fix this.

>
> +Datum
> +pg_reload_conf_pid(PG_FUNCTION_ARGS)
> I think that the naming is closer to pg_reload_backend.
>
> Documentation is needed as well.

Agree with pg_reload_backend and I'll write the documetation.

>
> > 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.)
>
> That would be nice.

Sure. I'll create a new thread and attach the new patch to it.

>
> > 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.
>
> Yeah, that's independent from the patch above.

Agree. It would be another feature from pg_reload_backend and
I think it would be implmented as another patch.

> --
> Michael
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>