Doug Royer <Doug(at)Royer(dot)com> 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
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
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"
In response to
pgsql-hackers by date
|Next:||From: Robert Treat||Date: 2006-01-02 02:49:29|
|Subject: Re: psql & readline & win32|
|Previous:||From: Bruce Momjian||Date: 2006-01-02 02:09:38|
|Subject: Re: Checks for command string|