From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: syslogger line-end processing infelicity |
Date: | 2007-06-02 01:11:54 |
Message-ID: | 4660C3DA.5070202@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> The other little problem (which is the reason we like the stderr
> approach in the first place) is that not all the stderr output we want
> to capture comes from code under our control. This may not be a huge
> problem in production situations, since the main issue in my experience
> is being able to capture dynamic-linker messages when shlib loading fails.
> But it is a stumbling block in the way of any proposals that involve
> having a more structured protocol for the stuff going down the wire :-(
>
>
>
I don't think that need worry us about CSV output - AFAICS it's
redirected quite separately from stderr - more like syslog really, so
the CSV output *is* all from code under our control.
I'm pondering some very simple method of signalling the end of a CSV
line, like appending a null byte (which we would of course strip out, so
it would never appear on the file), and only allowing a CSV log rotation
if we are on a boundary.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2007-06-02 02:05:32 | Re: [HACKERS] like/ilike improvements |
Previous Message | Jim Nasby | 2007-06-02 00:13:54 | Re: To all the pgsql developers..Have a look at the operators proposed by me in my research paper. |