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. 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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
