| 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:58:52 |
| Message-ID: | CA+hUKG+JXKG=+U=demYXu0mVdhP3-ndf0gCk9LqRkZ03yh9qrw@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:
> I've managed to reproduce it using qemu-system-riscv64 with Debian trixie
Huh, that's interesting. What is the host architecture? When I saw
that error myself and wondered about memory order, I dismissed the
idea of trying with qemu, figuring that my x86 host's TSO would affect
the coherency, but thinking again about that... I guess the compiler
might still reorder during riscv codegen if there is something wrong
with the barrier support, and even if it doesn't, the binary
translation to x86 might also feel free to reorder stuff if there are
no barrier instructions to prevent it? Or maybe that doesn't happen
but your host is ARM?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2025-10-12 04:57:56 | Re: proposal: schema variables |
| Previous Message | Thomas Munro | 2025-10-12 03:35:02 | Re: IO in wrong state on riscv64 |