On Tue, Jul 28, 2015 at 2:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Kevin Grittner <kgrittn@ymail.com> writes: > Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Kevin Grittner <kgrittn@ymail.com> writes: >>> 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.
>> 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.
> That seems sufficient to me for normal cases.
Rather than remove the "sending signal" elog entirely, I reduced it to DEBUG1; that will avoid log chatter for normal cases but the info can still be obtained at need.
This part doesn't seem right to me. Now the autovac worker logs that it was cancelled, but we have no idea why it was cancelled i.e. which lock request caused it to be cancelled and which query caused the lock request.
(It looks like the build-farm failures were fixed by the other part of the change, which I have no objection to)
This effectively undoes commit d7318d43d891bd63e82dcfc27. I thought that that commit was a huge improvement and would prefer it not be undone.
The old message was at DEBUG2, so typically it didn't show up in the
log at all. As a result, in most cases where autovacuum was canceled,
the only information that was logged was the table being vacuumed,
with no indication as to what problem caused the cancel. Crank up
the level to LOG and add some more details to assist with debugging.
Although looking at the code from that patch, it is not clear to me why all the string building needs to be done under the ProcArrayLock. The string depends only on the local state of the lock being blocked, not on the proc doing the blocking.
