On Sat, Jun 24, 2017 at 5:07 AM, Alvaro Herrera
<alvhe...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
