Re: syslog_line_prefix - Mailing list pgsql-hackers

From Robert Haas
Subject Re: syslog_line_prefix
Date
Msg-id 603c8f070909251318k1d8acb6ay6a1e2da543930f8a@mail.gmail.com
Whole thread Raw
In response to Re: syslog_line_prefix  (Magnus Hagander <magnus@hagander.net>)
Responses Re: syslog_line_prefix
Re: syslog_line_prefix
List pgsql-hackers
On Fri, Sep 25, 2009 at 4:06 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Fri, Sep 25, 2009 at 21:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> "Joshua D. Drake" <jd@commandprompt.com> writes:
>>> On Mon, 2009-09-14 at 09:43 +0900, Itagaki Takahiro wrote:
>>>> We have a tip that log_line_prefix is not required for syslog
>>>> in the documentation, but we'd better to have independent setttings
>>>> if we set log_destination to 'stderr, syslog'.
>>
>>> IMO we should just make log_line_prefix work with syslog/eventlog too.
>>
>> It *does* work with syslog.  You missed the point, which is that because
>> syslog sticks on timestamp and PID information of its own accord, you'd
>> typically want a different prefix setting for syslog than for stderr.
>>
>> However, I don't think I actually believe the premise of this patch,
>> which is that sending log information to both stderr and syslog is
>> a useful thing to do --- so useful that it's worth greatly complicating
>> the elog stuff to support it a trifle better.  Given the amount of
>> whining we hear about the overhead of logging, who is going to want
>> duplicate output?  And especially, who is going to want elog.c to do
>> twice as much work to format the log output differently for the two
>> destinations?
>
> I am :-)
>
> I definitely want both text and CSV output - which I can't have today.

Huh?  I thought I had that exact configuration working yesterday.

> I would even more like to have some things send to CSV and some things
> sent to text.

This patch won't help, then.

> Other than if you're logging all your queries (or over <n> time, where
> <n> is very small), I've never seen a system with performance issues
> from logging. I'm sure others may have, but not me.
>
> Is there really any log output other than the
> query-logging-for-performance-analysis that is likely to cause any
> real load on the system? If not, perhaps we need to break out that
> part to a separate codepath instead, and optimize that one for speed,
> while optimizing the other paths for flexibility?

Not sure, but I doubt it's that easy.

...Robert


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: syslog_line_prefix
Next
From: Marko Kreen
Date:
Subject: Re: [COMMITTERS] pgsql: Unicode escapes in E'...' strings Author: Marko Kreen