Re: BUG #16827: macOS interrupted syscall leads to a crash

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: ricardoungureanu(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16827: macOS interrupted syscall leads to a crash
Date: 2021-01-26 08:26:03
Message-ID: CA+hUKGKdYnhmOWWpMAUtGjmHJK+JsC+G87Djutn3JcFfJxc-7Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, Jan 16, 2021 at 3:17 AM PG Bug reporting form
<noreply(at)postgresql(dot)org> 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.
>
> Please let me know if you need more details about this. The bug can be
> easily replicated, but a fairly complicated setup has to be done beforehand
> (large db dump, macOS 11.0, endpoint security events enabled).

I wonder if this also explains why pg_test_fsync's final measurement
"non-sync", which does open(), write(), close() in a loop, only
manages around 50k loops per second on an M1 Air, but around a million
on contemporary laptops running Linux and FreeBSD, though I don't have
a Catalina system to compare with.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Hamid Akhtar 2021-01-26 09:07:09 Re: Bug in error reporting for multi-line JSON
Previous Message PG Bug reporting form 2021-01-26 07:00:00 BUG #16837: Invalid memory access on \h in psql