On Fri, Sep 09, 2011 at 10:27:22AM -0400, Tom Lane wrote: > George Barnett <gbarn...@atlassian.com> writes: > > [ patch to retry writes on NFS ] > > I'm having a hard time getting excited about this idea, because IMO > NFS is insufficiently reliable to run a database on, and no patch like > this can fix that. However, some concrete points: > > 1. If writes need to be retried, why not reads? (No, that's not an > invitation to expand the scope of the patch; it's a question about NFS > implementation.)
To support all POSIX:2008-conforming read() implementations, we must indeed retry reads. I suppose the OP never encountered this in practice, though. > 2. What is the rationale for supposing that a retry a nanosecond later > will help? If it will help, why didn't the kernel just do that? POSIX:2008 unconditionally permits[1] partial writes of requests exceeding 512 bytes (_POSIX_PIPE_BUF). We shouldn't complain when a kernel provides a conforming write(), even if it appears that the kernel achieved little by using some freedom afforded it. > 3. What about EINTR? If you believe that this is necessary, then the > kernel logically has to return EINTR when it would like you to retry but > it hasn't been able to write any bytes yet. If you get a zero return > you have to assume that means out-of-disk-space. Assuming conforming SA_RESTART for write()/read(), this will not happen. The call will restart and resume blocking until it writes something. nm [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers