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.
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 |