Re: Buildfarm failure from overly noisy warning message
От | Tom Lane |
---|---|
Тема | Re: Buildfarm failure from overly noisy warning message |
Дата | |
Msg-id | 25404.1438119491@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Buildfarm failure from overly noisy warning message (Kevin Grittner <kgrittn@ymail.com>) |
Ответы |
Re: Buildfarm failure from overly noisy warning message
|
Список | pgsql-hackers |
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. >> 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). > +1 for only printing for the non-ESRCH cases. Left that one as a WARNING, but it doesn't print for ESRCH. regards, tom lane
В списке pgsql-hackers по дате отправления: