Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers |
Дата | |
Msg-id | CAB7nPqQZUSgCC_r=bchFPFdQ0gpjb99Ne4r3ZbmhxJDTLo1ttg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers
|
Список | pgsql-hackers |
On Sat, Jun 24, 2017 at 5:07 AM, 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? 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. +Datum +pg_reload_conf_pid(PG_FUNCTION_ARGS) I think that the naming is closer to pg_reload_backend. Documentation is needed as well. > 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. > 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. -- Michael
В списке pgsql-hackers по дате отправления: