Hi,
On 2021-01-15 14:00:03 +0000, PG Bug reporting form wrote:
> I am using macOS 11.0 and trying to import a large dump into postgresql.
> Under some circumstances, it crashes while importing.
> I inspected the logs and found out a system call is interrupted (" LOG:
> could not open file "pg_wal": Interrupted system call"). Apple has added a
> new feature in macOS 11.0 to audit security events. I noticed that the
> kernel, while waiting on a condition variable, if it receives an interrupt,
> will just pass EINTR (error code 4) back to the usermode program. Your
> function XLogFileInit does not treat such cases (just ENOENT is checked) and
> decides to exit with an abort(). I have attached below the crash file
> generated.
Hm. It's fairly nasty to return EINTR from open() (except if open()ing a
FIFO or such) - it should normally only happen when blocked. But I'm not
sure it's *actually* violating any standards / promises made.
> Apple has added a new feature in macOS 11.0 to audit security
> events. I noticed that the kernel, while waiting on a condition
> variable, if it receives an interrupt, will just pass EINTR (error
> code 4) back to the usermode program.
Does that also happen for close()? Because that can't reasonably be
handled by userspace (userspace cannot retry because the fd could now
point to something else in a threaded environment).
Greetings,
Andres Freund