On 14 Oct 2003, Greg Stark wrote: > > Michael Brusser <[EMAIL PROTECTED]> writes: > > > > Michael Brusser <[EMAIL PROTECTED]> 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? :-) ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
