Re: Buildfarm failure from overly noisy warning message

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Buildfarm failure from overly noisy warning message
Дата
Msg-id CAMkU=1yZwXFj4PQ301eVPhYXE7BERi-azcZwn6nA418B30BBqA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Buildfarm failure from overly noisy warning message  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Buildfarm failure from overly noisy warning message  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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. 

commit d7318d43d891bd63e82dcfc27948113ed7b1db80
Author: Robert Haas <rhaas@postgresql.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [PROPOSAL] Table Partition
Следующее
От: Anastasia Lubennikova
Дата:
Сообщение: [PROPOSAL] Effective storage of duplicates in B-tree index.