Re: Buildfarm failure from overly noisy warning message

On Tue, Jul 28, 2015 at 2:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Kevin Grittner <kgrittn(at)ymail(dot)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.

commit d7318d43d891bd63e82dcfc27948113ed7b1db80
Author: Robert Haas <rhaas(at)postgresql(dot)org>
Date: Thu Jul 26 09:18:32 2012 -0400

Log a better message when canceling autovacuum.

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.

Cheers,

Jeff