Skip site navigation (1) Skip section navigation (2)

Re: syslog_line_prefix

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Joshua Tolley <eggyknap(at)gmail(dot)com>, jd <jd(at)commandprompt(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: syslog_line_prefix
Date: 2009-09-28 14:43:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
[ please trim the quoted material a bit, folks ]

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> 2009/9/28 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> The problem with having the syslogger send the data directly to an
>> external process is that the external process might be unable to
>> process the data as fast as syslogger is sending it. I'm not sure
>> exactly what will happen in that case, but it will definitely be bad.

This is the same issue already raised with respect to syslog versus
syslogger, ie, some people would rather lose log data than have the
backends block waiting for it to be written.

> That would mean we have to write everything to the file, though, so it
> would be rather bad for the case where you want to log "just a little"
> but are "delegating" the decision to the external process. And it
> would create double the I/O on disk for the logfile (once to the csv
> log, once processed by the external process).

Robert's design could be made to work without that, if you dump the
original log output into a ramdisk and let the external process write
whatever it chooses to real disk.  If you have a system crash you lose
any as-yet-unprocessed log output, but hopefully there usually wouldn't
be much.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-09-28 14:46:07
Subject: Re: Rejecting weak passwords
Previous:From: Magnus HaganderDate: 2009-09-28 14:24:17
Subject: Re: Rejecting weak passwords

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group