Yes - if you assume that EINTR only happens on NFS mounts.
My point is that independent of NFS, the error checking
that I have found in the code is not complete even for
non-NFS file systems.
The read() and write() LINUX man pages do NOT specify that EINTR
is an NFS-only error.
EINTR The call was interrupted by a signal before any data was
read.
The read() and write() SOLARIS man pages say:
EINTR A signal was caught during the read operation and no
data was transferred.
There are other SVR read() and write() errors:
EOVERFLOW (read)
The file is a regular file, nbyte is greater than 0,
the starting position is before the end-of-file, and
the starting position is greater than or equal to the
offset maximum established in the open file descrip-
tion associated with fildes.
EDEADLK
The write was going to go to sleep and cause a
deadlock situation to occur.
EDQUOT
The user's quota of disk blocks on the file system
containing the file has been exhausted.
EFBIG (write)
An attempt is made to write a file that exceeds the
process's file size limit or the maximum file size
(see getrlimit(2) and ulimit(2)).
EFBIG The file is a regular file, nbyte is greater than 0,
and the starting position is greater than or equal to
the offset maximum established in the file description
associated with fildes.
ENOSPC
During a write to an ordinary file, there is no free
space left on the device.
Bruce Momjian wrote:
> Let me give you a sky-high view of this. Database reliability requires
> that the disk drive be 100% reliable. If any part of the disk storage
> fails (I/O write failure, NFS failure) we have to assume that the disk
> storage is corrupt and the database needs to be restored from backup.
> The NFS failure modes seem to suggest that any kind of NFS failure makes
> our storage suspect, meaning we want NFS to be as non-failure mode as
> possible. Making PostgreSQL work on NFS system itself is risky, and
> allowing it to work on systems that will soft-failure on writes seems
> even worse.
>
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
We Do Standards - You Need Standards