Re: Non-reproducible AIO failure
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>,
Alexander Lakhin <exclusion@gmail.com>, Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org
Date: 2025-05-27T19:18:50Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
aio: Stop using enum bitfields due to bad code generation
- ce161b194e84 18.0 landed
- 5865150b6d53 19 (unreleased) landed
-
amcheck: Fix posting tree checks in gin_index_check()
- 0cf205e122ae 18.0 cited
-
aio: Add missing memory barrier when waiting for IO handle
- e9a3615a5224 18.0 landed
On Sun, May 25, 2025 at 8:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > The fact that I can trace through this Assert failure but not the > AIO one strongly suggests some system-level problem in the latter. > There is something rotten in the state of Denmark. I have been quite frustrated with lldb on macOS for a while now -- I tend to find that when I get a can get stack trace from a still-running process it works fine, but trying to get a stack trace from a core dump often fails to produce anything useful (but sometimes it does produce something useful). I haven't been able to find any information on the Internet to explain why this sometimes happens and sometimes doesn't, and various things I attempted as fixes didn't work out. There could be something wrong specifically with this machine, but I also wouldn't be too shocked if this is just randomly broken on macOS. -- Robert Haas EDB: http://www.enterprisedb.com