Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
+1 on that. The problem of ensuring atomic output remains though
(see nearby complaints from George Pavlov and others).
Is that the one you suggested trying to fix by calling write() instead
of fprintf()? If so, I can't think of any good reason not to do that
anyway.
Probably not, but it doesn't fix the problem for long log lines (more
than PIPE_BUF bytes).
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 have been trying to think of how we can get around the problem of
multiplexing our own output inappropriately. I have no great insights,
but I did think of these:
. use one pipe per backend instead of one per postmaster, and have the
syslogger poll them all.
. use a mutex to control access to the pipe
. same as previous but use a worker thread for each backend to do
logging so blocking on the mutex wouldn't block the backend
All of these look like a lot of work for a relatively infrequent
problem, not to mention plenty of other disadvantages.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
