On Wed, May 24, 2006 at 12:16:13AM +0200, Florian G. Pflug wrote:
> >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.
> AFAIK, linux actually abort syscalls when an signal arrives, and it's
> just the libc that restarts them automatically. So, actually, doing
All UNIX OS's do something similar. After all, if you define a signal
handler, the kernel has to return to user space to execute your
handler. All BSD did was always restart the syscall (your loop, though
probably just by fiddling the instruction pointer)) whereas SysV never
did. Nowadays you can choose which way you want it using sigaction().
I think the real lesson is that you can emulate BSD semantics if you
have SysV semantics, but not vice-versa.
> >Postgres doesn't check EINTR on all filesystem system call and thus
> >would be susceptable to the above problem.
> Even if postgres checked for EINTR, what could it possibly do in that case?
> Just retrying wont have any advantage over simply mounting with "nointr" -
> it would still just hang when the nfs-server dies.
Well, it could check whether statement_tineout has passed and return an
error rather than hanging...
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.