On Mon, May 22, 2006 at 12:52:33PM -0400, Greg Stark wrote:
> "Rafael Martinez, Guerrero" <r.m.guerrero@usit.uio.no> writes:
>
> > Why do you think 'intr' is a bad thing, from man pages:
> > " ........ If an NFS file operation has a major timeout and it is
> > hard mounted, then allow signals to interupt the file operation and
> > cause it to return EINTR to the calling program. The default is to not
> > allow file operations to be interrupted ....."
>
> Traditional file systems guaranteed it never happened, so older applications
> do not expect to have filesystem operations interrupted. Many do not check for
> it or do not handle it properly. I recall a conversation a while back about
> Postgres in particular not checking for it.
I've occasionally wondered if this is a SysV vs BSD thing. Under SysV
signal semantics, any signal would cause the current system call to
return EINTR. The list of system calls that could be interrupted is
long, and include just about anything filesystem related. So programs
with any kind of signal handling would handle the broken-NFS case
automatically.
BSD signal semantics (what postgres uses) make all system calls
restart across signals. Thus, a system call can never return EINTR
unless you have non-blocking I/O enabled. These programs would be
confused by unexpected EINTRs.
Postgres doesn't check EINTR on all filesystem system call and thus
would be susceptable to the above problem.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.