Re: EINTR causes panic (data dir on btrfs)

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Gustavo Lopes wrote:
>> ... Why wouldn't postgres retry on EINTR or even
>> allow return values of write() lower than nbytes (and then continue in a
>> loop).

> I happened to notice this report from 15 months ago, which didn't get
> any response. Did you find a solution to this problem? I would first
> blame btrfs, mostly because I've never heard of anyone with this problem
> on more mainstream filesystems. As I recall, we use SA_RESTART almost
> everywhere so we don't expect EINTR anywhere.

On my RHEL6 box, the signal(7) man page specifically states that write()
to a disk file will not return EINTR if interrupted by a signal handler
with SA_RESTART set:

If a blocked call to one of the following interfaces is interrupted by
a signal handler, then the call will be automatically restarted after
the signal handler returns if the SA_RESTART flag was used; otherwise
the call will fail with the error EINTR:

* read(2), readv(2), write(2), writev(2), and ioctl(2) calls on
"slow" devices. A "slow" device is one where the I/O call may
block for an indefinite time, for example, a terminal, pipe, or
socket. (A disk is not a slow device according to this defini-
tion.) If an I/O call on a slow device has already transferred
some data by the time it is interrupted by a signal handler, then
the call will return a success status (normally, the number of
bytes transferred).

We set SA_RESTART on every signal that we set an interrupt handler for.
So it's hard to avoid the conclusion that btrfs has broken the API
contract specified by signal(7).

A bit of googling suggests that at least one such case used to exist
in btrfs but has been fixed:

http://linux-btrfs.vger.kernel.narkive.com/CbodH9VP/patch-btrfs-don-t-return-eintr

I wonder what kernel version the OP was using.

regards, tom lane