Re: EINTR error in SunOS

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