4 ms·

I wonder if EINTRs are now returned from syscalls that were always documented to (sometimes) return them in POSIX/SUS/other documentation but PostgreSQL simply

I wonder if EINTRs are now returned from syscalls that were always documented to (sometimes) return them in POSIX/SUS/other documentation but PostgreSQL simply ignored that possibility with Mach, or if they are returned from some completely unexpected places?

dfox 6y ago
This seems to be the case. On the other hand mostly everybody ignores the fact that open(2) is documented as possibly returning -EINTR, because it essentially never happens (in particular, network filesystem are usually implemented in a way that it will not happen even in situations when it clearly should happen).
- deleted 6y ago
  [deleted]
viraptor 6y ago
It's returned from open() https://www.postgresql.org/message-id/CAFHbkwjPXHgWb15wsmaCMuYOOF2Fm6sBVj9Sv1LbwRav75KsRg%40mail.gmail.com https://www.postgresql.org/message-id/CAFHbkwjPXHgWb15wsmaCM... https://pubs.opengroup.org/onlinepubs/9699919799/ https://pubs.opengroup.org/onlinepubs/9699919799/ Posix is happy with returning EINTR.
- cesarb 6y ago
  That documentation says "[EINTR] A signal was caught during open().", and the documentation there for sigaction with SA_RESTART says "If set, and a function specified as interruptible is interrupted by this signal, the function shall restart and shall not fail with [EINTR] unless otherwise specified.", so as long as all signals were installed with SA_RESTART (which is probably the most common case since nobody likes dealing with EINTR), open() should never fail with EINTR.
- tzs 6y ago
  This from that PostgreSQL mailing list link you give is interesting: > AUTH means that the system call is blocked (on that condition variable I mentioned about), and the user mode daemon is asked about the generated event: "postgres, pid 999, open() on file /path/file with flags 0x400003" - something like that. The usermode can either allow or deny the event by replying. The use of a user mode daemon to make decisions about whether file access is allowed reminds me of the way TOPS-10 on DEC PDP-10 did access control lists over 40 years ago. It's a method I'd like to see for ACLs on modern systems. On modern systems the ACL is part of the per file metadata. On TOPS-10 the ACL information was in a separate file that contained the ACL information for multiple files. I don't remember if is was one ACL file per user or one per directory. An ACL entry could specify file name (wildcards allowed), account and group requesting access (wildcards allowed), program that was requesting access, and what kind of access. The wildcards and the centralization of the ACLs for multiple files is what made this system excellent to use. When an access was attempted the system first checked if it was allowed by the ordinary per file permissions. If it was access was granted and the ACL daemon was not consulted. If the ordinary permissions denied access and the caller had not set a flag indicating it did not want to check the ACLs the access was denied. If that flag was not set the kernel would consult the access daemon, which would find the ACL file and check the ACLs within to find the ones that applied and make its decision.
  - jtchang 6y ago
    Funny how we are still learning from what we built 40 years ago.
jandrewrogers 6y ago
I believe EINTR was always a possibility per the docs. This case has always been handled correctly in a few other storage engine code bases, and that code was unlikely to have been written for no reason even if EINTR never occurred in practice. This seems to be a case of not checking or allowing for all possible return codes.

dfox 6y ago

This seems to be the case. On the other hand mostly everybody ignores the fact that open(2) is documented as possibly returning -EINTR, because it essentially never happens (in particular, network filesystem are usually implemented in a way that it will not happen even in situations when it clearly should happen).

deleted 6y ago
[deleted]

viraptor 6y ago

It's returned from open() https://www.postgresql.org/message-id/CAFHbkwjPXHgWb15wsmaCMuYOOF2Fm6sBVj9Sv1LbwRav75KsRg%40mail.gmail.com https://www.postgresql.org/message-id/CAFHbkwjPXHgWb15wsmaCM... https://pubs.opengroup.org/onlinepubs/9699919799/ https://pubs.opengroup.org/onlinepubs/9699919799/ Posix is happy with returning EINTR.

cesarb 6y ago
That documentation says "[EINTR] A signal was caught during open().", and the documentation there for sigaction with SA_RESTART says "If set, and a function specified as interruptible is interrupted by this signal, the function shall restart and shall not fail with [EINTR] unless otherwise specified.", so as long as all signals were installed with SA_RESTART (which is probably the most common case since nobody likes dealing with EINTR), open() should never fail with EINTR.
tzs 6y ago
This from that PostgreSQL mailing list link you give is interesting: > AUTH means that the system call is blocked (on that condition variable I mentioned about), and the user mode daemon is asked about the generated event: "postgres, pid 999, open() on file /path/file with flags 0x400003" - something like that. The usermode can either allow or deny the event by replying. The use of a user mode daemon to make decisions about whether file access is allowed reminds me of the way TOPS-10 on DEC PDP-10 did access control lists over 40 years ago. It's a method I'd like to see for ACLs on modern systems. On modern systems the ACL is part of the per file metadata. On TOPS-10 the ACL information was in a separate file that contained the ACL information for multiple files. I don't remember if is was one ACL file per user or one per directory. An ACL entry could specify file name (wildcards allowed), account and group requesting access (wildcards allowed), program that was requesting access, and what kind of access. The wildcards and the centralization of the ACLs for multiple files is what made this system excellent to use. When an access was attempted the system first checked if it was allowed by the ordinary per file permissions. If it was access was granted and the ACL daemon was not consulted. If the ordinary permissions denied access and the caller had not set a flag indicating it did not want to check the ACLs the access was denied. If that flag was not set the kernel would consult the access daemon, which would find the ACL file and check the ACLs within to find the ones that applied and make its decision.
- jtchang 6y ago
  Funny how we are still learning from what we built 40 years ago.

jandrewrogers 6y ago

I believe EINTR was always a possibility per the docs. This case has always been handled correctly in a few other storage engine code bases, and that code was unlikely to have been written for no reason even if EINTR never occurred in practice. This seems to be a case of not checking or allowing for all possible return codes.