On 14 Oct 2003, Greg Stark wrote:
>
> Michael Brusser <michael@synchronicity.com> writes:
>
> > > Michael Brusser <michael@synchronicity.com> writes:
> > > > 2003-10-10 22:37:05 ERROR: cannot read block 0 of s_noteimportlinks:
> > > > Interrupted system call
> > >
> > > Hmm. I found this hard to believe at first, but indeed my local man
> > > pages for read() and write() say they can return EINTR if interrupted
> > > by a signal. This may depend on the filesystem in use (are you using
> > > NFS?)
>
> The traditional unix semantics are the read/write my return EINTR if
> interrupted -- but that that would only EVER happen for network connections.
> The traditional semantics are that it would NEVER happen on disk i/o. BSD
> kernels at least, and probably all unix kernels, do an uninterruptible sleep
> on disk accesses, hence the dreaded "D" in ps listings.
>
> > Yes, we use NFS. Many of our customers use it as well.
>
> Normally NFS guarantees the traditional unix semantics.
> Unless you're using either "soft" or "intr" options.
>
> If you are, well, stop.
>
> If you use "intr" then this type of thing can happen. Lots of programs assume
> the unix semantics for disk accesses. You can get all kinds of bugs when
> they're violated.
>
> If you use "soft" then the consequences can be much much worse. If your
> fileserver were to reboot you could silently lose disk writes corrupting your
> database.
What if the WAL was local on disk, and the data was going to nfs storage,
would that be safe, or saferer? :-)