Re: new compiler warnings
От | Robert Haas |
---|---|
Тема | Re: new compiler warnings |
Дата | |
Msg-id | CA+TgmoaFOj8cWPnjQfd0KgLLsqCabMK_VGszbBvcj2iU-B53+w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: new compiler warnings (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: new compiler warnings
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: