Re: syslog_line_prefix

On Fri, Sep 25, 2009 at 4:06 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Fri, Sep 25, 2009 at 21:19, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> "Joshua D. Drake" <jd(at)commandprompt(dot)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