On Thu, Nov 19, 2009 at 3:50 AM, Andrew Dunstan and...@dunslane.net wrote:
I'm fine with that. I don't remember whether I put that in or whether it
came from the original patch author(s). Either way, I assume the reason was
to explain why the message appeared on stderr rather than the CSVlog.
Greg Stark gsst...@mit.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
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
Andrew Dunstan and...@dunslane.net writes:
So the logger there has been doing CSV logging for quite a while without
memory ballooning.
I was able to generate a noticeable leak by cranking log_rotation_size
way down ... it's about 1K per size rotation event.
regards,
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
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
Tom Lane wrote:
In any case
there will certainly always be *some* postmaster messages that could
be emitted after setting the log_destination GUC and before launching
the syslogger child. If the designed behavior is that we dump to
stderr during that interval, we should just do it, without
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
