On Tue, Oct 18, 2011 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Oct 18, 2011 at 12:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> And it would break the code. The whole point here is that the message
>>> must be sent indivisibly.
>
>> How is that different than the chunking that the while loop is already doing?
>
> 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.
The man page for read(2) says:
Upon successful completion, read(), readv(), and pread() return
the number of bytes actually read and placed in the buffer. The system
guarantees to read the number of bytes requested if the descriptor references a normal
file that has that many bytes left before the end-of-file, but in no other case.
In any event, whether or not it's *possible* to have a short read is a
separate question from what we should do if it happens. Retrying an
error doesn't seem practical, because in all likelihood the error will
recur forever and we'll go into an infinite loop. But if we do
somehow get a short write, sending the rest of the current chunk in
the next write() does not seem materially worse than sending the next
chunk.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company