Re: new compiler warnings

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql(at)j-davis(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: new compiler warnings
Date: 2011-10-18 17:44:19
Message-ID: 4E9DBAF3.90803@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/18/2011 01:35 PM, Tom Lane wrote:
> Robert Haas<robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Oct 18, 2011 at 1:01 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-10-18 18:46:41 Re: [v9.2] Object access hooks with arguments support (v1)
Previous Message Tom Lane 2011-10-18 17:35:13 Re: new compiler warnings