Kevin Grittner <kgri...@ymail.com> writes:
> Tom Lane <t...@sss.pgh.pa.us> wrote:
>> 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 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().
Hm. By that logic, I'm not sure if we need anything to be logged here,
because the autovacuum process will log something about having received
a query cancel signal. Also, if we do it like that there's a race
condition: it's entirely possible (maybe even likely, on single-CPU
machines) that the autovacuum process would issue its log entry before
the sender is able to log its request. That would probably confuse people
no end.
If we're in the business of minimizing log chatter, I'd suggest that
we remove the entirely-routine "sending cancel" log message, and only
log something in the uncommon case where the kill() fails (but, per
original point, reduce that entry to LOG or so; or else print something
only for not-ESRCH cases).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
