From: | Doug McNaught <doug(at)mcnaught(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: EINTR error in SunOS |
Date: | 2006-01-02 02:09:47 |
Message-ID: | 87y81zbct0.fsf@asmodeus.mcnaught.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2006-01-02 02:49:29 | Re: psql & readline & win32 |
Previous Message | Bruce Momjian | 2006-01-02 02:09:38 | Re: Checks for command string |