Tom Lane <tgl@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
