On Fri, Sep 25, 2009 at 4:06 PM, Magnus Hagander <mag...@hagander.net> wrote: > On Fri, Sep 25, 2009 at 21:19, Tom Lane <t...@sss.pgh.pa.us> wrote: >> "Joshua D. Drake" <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
