Re: [PATCH v1] Fix races in Windows pthread emulation

Thanks for the review and additional reproductions. ARM64 was where I
reproduced the hang; I didn’t mean to imply the mutex race was
ARM64-specific. I haven’t established the performance impact or
backpatch compatibility of the pthread_once change. Would it make
sense to separate that from the mutex fix? Alexander, thanks for
offering to test.

On Mon, 05 Oct 2026 21:00:00 +0300, Alexander Lakhin
<exclusion(at)gmail(dot)com> wrote:
> Hello hackers,
>
> 05.10.2026 18:48, Heikki Linnakangas wrote:
> > On 20/08/2026 15:09, Nazir Bilal Yavuz wrote:
> >> On Fri, 24 Jul 2026 at 10:07, Harrison Booth <harrisontbooth(at)gmail(dot)com> wrote:
> >>>
> >>> On native Windows ARM64, the ECPG thread/alloc test could hang until
> >>> Meson's 1000-second timeout. The cause was a race in the Windows pthread
> >>> mutex emulation.
> >>
> >> I ran into this exact issue today [1] and found your thread.
> >
> > Is there some memory ordering reason why this only happens on ARM64? AFAICS, it could happen on x86 too.
>
> FWIW, it also occurred on AMD64 animal hamerkop (twice in this year):
> [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2026-09-24%2014%3A35%3A01
> [2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2026-03-26%2015%3A35%3A04 (ecpgCheck [fb072e1]
> (01:10:46))
>
> I also managed to reproduce the hang locally, running 6 ecpg tests
> concurrently on a Windows x86_64 VM, so I can test the patch if needed.
>
> Best regards,
> Alexander