| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, greg(at)burd(dot)me |
| Subject: | Re: IO in wrong state on riscv64 |
| Date: | 2025-11-08 00:10:58 |
| Message-ID: | 27tuf532vli5w5g3lu567ojox4bevgdbekqho7r3phlno6xfjg@vs2zj6bi3i72 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2025-11-07 19:03:46 -0500, Tom Lane wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > Alexander did some extensive testing and we stared at the codegen on a
> > lot of architectures to confirm that this prevents the reordering.
> > Pushed and back-patched like that.
>
> You're a brave man to be pushing this into the last-ever release
> of v13 with all of 12 hours remaining till code freeze. I don't
> mind so much for the newer branches, but I'm feeling nervous
> about the risk/reward ratio for v13.
The patch doesn't do anything complicated, it just adds a compiler barrier to
the read/write barriers. As both the compiler barrier and read/write barrier
code is old I don't see a whole lot of potential for problems here. If this
were changing inline assembly or such, it'd be a different story...
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2025-11-08 00:13:32 | Re: IO in wrong state on riscv64 |
| Previous Message | Tom Lane | 2025-11-08 00:03:46 | Re: IO in wrong state on riscv64 |