Jeff Janes <jeff.janes@gmail.com> writes:
> On Tue, Jul 28, 2015 at 2:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
The argument for changing it was basically that there's not any very good
reason to care, and if this happens a lot you're just bloating the log.
While I am not going to defend that proposition to the death, I've
certainly heard plenty of complaints that the postmaster log is too chatty
about routine occurrences. Why is this information important enough
to log by default?
> 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.
Actually, I'm not sure I see the point of taking the ProcArrayLock at all
in this stanza. If the state of the autovac process can change under us
then the lines just in front of the LWLockAcquire are already broken, no?
Worst case, the blocker might not be there at all anymore.
regards, tom lane
