Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The idea of one pipe per process is not really workable, because it
> would mean having as many pipes as backends which does not sound very
> good.  But how about a mixed approach -- like have the all the backends
> share a pipe, controlled by an LWLock, and the auxiliary process have a
> separate pipe each?

Multiple pipes seem like a mess, and in any case the above still doesn't
work for stderr output produced by non-cooperative software (dynamic
loader for instance).

The only solution that I can see is to invent some sort of simple
protocol for the syslogger pipe.  Assume that the kernel honors PIPE_BUF
(this assumption may need proving, see other message).  We could imagine
having elog.c divvy up its writes to the pipe into chunks of less than
PIPE_BUF bytes, where each chunk carries info sufficient to let it be
reassembled.  Perhaps something on the order of

        \0 \0 2-byte-length source-PID end-flag text...

The syslogger reassembles these by joining messages with the same
origination PID, until it gets one with the end-flag set.  It would need
enough code to track multiple in-progress messages.

The logger would have to also be able to deal with random text coming
down the pipe (due to aforesaid non-cooperative software).  I would be
inclined to say just take any text not preceded by \0\0 as a standalone
message, up to the next \0\0.  Long chunks of non-protocol text would
risk getting treated as multiple messages, but there's probably not a
lot of harm in that.

BTW, exactly what is the COPYable-logs code going to do with random
text?  I trust the answer is not "throw it away".

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to