Re: syslog_line_prefix

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.
I would even more like to have some things send to CSV and some things
sent to text.

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?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/