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 →
  1. aio: Stop using enum bitfields due to bad code generation

  2. amcheck: Fix posting tree checks in gin_index_check()

  3. aio: Add missing memory barrier when waiting for IO handle

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