Doug Royer <[EMAIL PROTECTED]> writes:
> 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.
Right, but I think that's because read() and write() also work on
sockets and serial ports, which are always interruptible. I have not
heard of local-disk filesystem code on any Unix I've seen ever giving
EINTR--a process waiting for disk is always in D state, which means
it's not interruptible by signals. If I have the time maybe I'll
grovel through the Linux sources and verify this, but I'm pretty sure
of it.
I'm not a PG internals expert by any means, but my $0.02 on this is
that we should:
a) recommend NOT using NFS for the database storage
b) if NFS must be used, recommend 'hard,nointr' mounts
c) treat EINTR as an I/O error (I don't know how easy this would be)
d) say "if you mount 'soft' and lose data, tough luck for you"
-Doug
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
