| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: IO in wrong state on riscv64 |
| Date: | 2025-10-12 03:35:02 |
| Message-ID: | CA+hUKG+X=FKYecrpZaWNkWJZkQQWu6v2LvcD4nof1UftF7nZ9A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Oct 12, 2025 at 2:00 AM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> 2025-10-11 11:34:46.793 GMT [1169773:1] PANIC: !!!pgaio_io_wait| ioh->state changed from 0 to 1 at iteration 0
> # no other iteration number observed
Can you please disassemble pgaio_io_update_state() and
pgaio_io_was_recycled()? I wonder if the memory barriers are not
being generated correctly, causing the state and generation to be
loaded out of order, or something like that...
The previous failure on greenfly was a TIMEOUT in the same test, as if
a query was hanging.
I've also been trying to understand two failures on CI on x86 with the
same symptom, but that might be something else, hard to say yet...
https://cirrus-ci.com/task/5551651043409920
https://www.postgresql.org/message-id/CA%2BhUKG%2BHh7u3YpPLKQS%2BB7KJu0Bw99EjhuPuvBRVccDfgod95g%40mail.gmail.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2025-10-12 03:58:52 | Re: IO in wrong state on riscv64 |
| Previous Message | Tom Lane | 2025-10-12 01:25:20 | Re: [PING] [PATCH v2] parallel pg_restore: avoid disk seeks when jumping short distance forward |