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