This EINTR is returned here for attempts at file accesses trapped by an antivirus/security layer, which can indeed take an undetermined amount of time, without the OS knowing how long that is...
Probably was a hard choice to make for Apple too. Should a thread be frozen for an undetermined amount of time while an antivirus does the check?
> Should a thread be frozen for an undetermined amount of time while an antivirus does the check?
It certainly does on other OSes and on previous versions of this one?
Do you really want to rewrite all existing software because it would be nice in 0.01% of cases that a thread is not "blocked" by an antivirus on file open, and can actually do something else, and that not on a specialized API but on good old syscalls? From a system design point of view that makes no sense.
> Do you really want to rewrite all existing software because it would be nice in 0.01% of cases that a thread is not "blocked" by an antivirus on file open
No. First, it's not a rewrite but a bugfix patch. Second, you will want this fix because open can return EINTR. It's documented. The code (postgresql in this case) is wrong. It should be fixed. simple.
POSIX is full of aspects that all OS provide greater guarantees or in some cases even deviates. It makes no sense to gratuitously / carelessly remove some of those guarantees and ask the world to fix their "obviously" broken programs that nevertheless worked perfectly on this (previously not really disputed) point during decades -- especially if the advantages such changes seem to be able to provide are not clear at all...
I'd surprise if a antivirus on windows would fail the read attempt from random software instead of temporary hang it. It will most-likely to be blamed as a bad AV here. Instead of just accepted because apple always do the correct thing.
Probably was a hard choice to make for Apple too. Should a thread be frozen for an undetermined amount of time while an antivirus does the check?