Tom Lane <t...@sss.pgh.pa.us> wrote: > + WARNING: could not send signal to process 30123: No such process
> What's evidently happened here is that our session tried to boot an > autovacuum process off a table lock, only that process was gone by the > time we issued the kill() call. > I'm inclined to reduce the WARNING to LOG, and/or skip it altogether > if the error is ESRCH. > One could also argue that both of these ereports ought to be downgraded to > DEBUG1 > or less, since this mechanism is pretty well shaken out by now. > Thoughts? I think a LOG entry when an autovacuum process is actually canceled has value just in case it is happening on a particular table so frequently that the table starts to bloat. I see no reason to log anything if there is an intention to cancel an autovacuum process but it actually completes before we can do so. IMV the best solution would be to proceed straight to the kill() and only log something if it was found by kill(). -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
