Re: BUG #16827: macOS interrupted syscall leads to a crash
| От | Thomas Munro |
|---|---|
| Тема | Re: BUG #16827: macOS interrupted syscall leads to a crash |
| Дата | |
| Msg-id | CA+hUKGKdYnhmOWWpMAUtGjmHJK+JsC+G87Djutn3JcFfJxc-7Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | BUG #16827: macOS interrupted syscall leads to a crash (PG Bug reporting form <noreply@postgresql.org>) |
| Список | pgsql-bugs |
On Sat, Jan 16, 2021 at 3:17 AM PG Bug reporting form
<noreply@postgresql.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.
В списке pgsql-bugs по дате отправления: