Re: "Not safe to send CSV data" message

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: "Not safe to send CSV data" message
Date: 2009-11-23 02:46:21
Message-ID: 20863.1258944381@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <gsstark(at)mit(dot)edu> writes:
> ISTM the danger is that someone looks at the regular logs and isn't
> aware that some messages went to someplace else. In which case
> bleating to the someplace else is unhelpful.

Yes, that's my problem with it in a nutshell. Anybody who is smart
enough to look at the original stderr doesn't need the warning;
all it does is distract from the real messages.

> Perhaps it would be more useful if
> it set a flag and then once the regular logs are set up you output a
> regular warning that some errors were generated prior to switching and
> were sent to stderr.

That'd be nice, but I'm unconvinced that it is feasible. The uncaught
messages might have come from subprocesses, or from library code that
isn't polite enough to go through elog. We go to a lot of trouble to
be able to capture all such traffic once the logger process is alive.
Pretending that we can tell you about traffic we didn't capture
seems to me to be likely to instill a false sense of confidence.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-11-23 04:02:49 Re: Partitioning option for COPY
Previous Message Hiroshi Saito 2009-11-23 01:56:38 Re: forget patch win32.mak.