Re: "Not safe to send CSV data" message

Tom Lane wrote:
> So I went to investigate bug #5196: turned on log_destination = csvlog
> etc, and restarted the postmaster. I got this on stderr:
>
> 2009-11-18 20:08:52.104 EST : : LOG: loaded library "passwordcheck"
> Not safe to send CSV data
>
> The first line is a consequence of having still got
> shared_preload_libraries set from testing the new contrib/passwordcheck
> module. However, what I'm on the warpath about right now is the second
> line. That message is useless, not to mention not conformant to our
> style guidelines.

(donning armor)

Possibly.

> And the fact that it comes out at all suggests that
> the csvlog startup logic is rather broken. Comments?
>
>

Not sure why you say that. This can only happen very early in the
startup process before the postmaster has had a chance to finish setting
up the syslogger process and dup the pipes. As soon as that happens
redirection_done is set to true and this message is no longer possible.

My memory is fading a bit about this now, but ISTR we debated the logic
some when I was working to get this committed around 2 1/2 years ago.
It's quite possible we (or I) got it wrong, but I'm not sure what we
should be doing if the logger isn't ready yet.

BTW, re that bug, I recently turned on CSV logging under 8.3 for a
client running Suse 10.2 64bit, with fairly heavy usage. Here is the
current state of the non-client processes:

postgres 7080 0.0 0.4 12913224 267216 ? S Oct28 2:58
/usr/bin/postmaster -D /pg_database/pg_data1/pg
postgres 7087 0.1 0.0 99824 60696 ? Ss Oct28 30:32
postgres: logger process
postgres 7092 0.0 16.3 12919564 10791472 ? Ss Oct28 7:41
postgres: writer process
postgres 7093 0.0 0.0 12919256 10432 ? Ss Oct28 0:29
postgres: wal writer process
postgres 7094 0.0 0.0 12920892 3544 ? Ss Oct28 0:00
postgres: autovacuum launcher process
postgres 7095 0.0 0.0 34396 1904 ? Ss Oct28 0:05
postgres: archiver process last was 0000000100000205000000A3
postgres 7096 0.0 0.0 36156 2916 ? Ss Oct28 10:26
postgres: stats collector process

So the logger there has been doing CSV logging for quite a while without
memory ballooning. (The writer process, on the other hand, has eaten up
a boatload of memory, by the look of it)

cheers

andrew