On Mon, May 22, 2006 at 12:52:33PM -0400, Greg Stark wrote: > "Rafael Martinez, Guerrero" <r.m.guerrero@xxxxxxxxxxx> 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@xxxxxxxxx> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment:
signature.asc
Description: Digital signature
