Re: less log level for success dynamic background workers for 9.5

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: less log level for success dynamic background workers for 9.5
Date: 2015-06-23 13:20:21
Message-ID: CA+TgmoZAiUJ=hMQJBMssHsim+EB362DBN-wneWooDwGXCLh_nQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 22, 2015 at 9:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> On Tue, Jun 23, 2015 at 10:07 AM, Robert Haas wrote:
>>> On Mon, Jun 22, 2015 at 8:19 PM, Jim Nasby wrote:
>>>> Anything ever happen with this? I agree that LOG is to high for reporting
>>>> most (if not all) of these things.
>
>>> I think we should consider having a flag for this behavior rather than
>>> changing the behavior across the board.
>>> But then again, maybe we should just change it.
>>>
>>> What do others think?
>
>> A GUC just for that looks like an overkill to me, this log is useful
>> when debugging. And one could always have its bgworker call elog by
>> itself at startup and before leaving to provide more or less similar
>> information.
>
> I agree that we don't need YAGUC here, particularly not one that applies
> indiscriminately to all bgworkers. I'd vote for just decreasing the log
> level. The current coding is appropriate for a facility that's basically
> experimental; but as it moves towards being something that would be used
> routinely in production, the argument for being noisy in the log gets
> weaker and weaker.

I was thinking of a background worker flag, not a GUC.
BGWORKER_QUIET, or something like that. But I guess we ought to just
change it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-06-23 13:48:15 Re: Memory context at PG_init call ?
Previous Message Robert Haas 2015-06-23 13:18:06 Re: upper planner path-ification