On 10/18/2011 01:35 PM, Tom Lane wrote:
> Robert Haas<robertmhaas@gmail.com> writes:
>> On Tue, Oct 18, 2011 at 1:01 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>> The chunks are sent indivisibly, because they are less than the pipe
>>> buffer size. Read the pipe man page. It's guaranteed that the write
>>> will either succeed or fail as a whole, not write a partial message.
>>> If we cared to retry a failure, there would be some point in checking
>>> the return code.
>> On MacOS X v10.6.8, I see no such guarantee in the pipe(2) man page.
> Sorry, maybe write(2) is the place to look. The Single Unix Spec quoth
> (at http://pubs.opengroup.org/onlinepubs/9699919799/):
>
> Write requests to a pipe or FIFO shall be handled in the same
> way as a regular file with the following exceptions:
>
> There is no file offset associated with a pipe, hence each write
> request shall append to the end of the pipe.
>
> Write requests of {PIPE_BUF} bytes or less shall not be
> interleaved with data from other processes doing writes on the
> same pipe. Writes of greater than {PIPE_BUF} bytes may have data
> interleaved, on arbitrary boundaries, with writes by other
> processes, whether or not the O_NONBLOCK flag of the file status
> flags is set.
>
> If the O_NONBLOCK flag is clear, a write request may cause the
> thread to block, but on normal completion it shall return nbyte.
>
> Note the last in particular. Short writes are specifically disallowed
> on pipes.
>
> If this were not the case, the logging collector protocol would be
> useless.
>
>
My dim recollection is that Tom and I and maybe some others did tests on
a bunch of platforms at the time we introduced the protocol to make sure
it did work this way, since it's crucial to making sure we don't get
interleaved log lines.
cheers
andrew