Re: [PATCH v1] Fix races in Windows pthread emulation - Mailing list pgsql-hackers

From Alexander Lakhin
Subject Re: [PATCH v1] Fix races in Windows pthread emulation
Date
Msg-id 9073309f-1805-49a4-87b7-dbdd010cebd4@gmail.com
Whole thread
In response to Re: [PATCH v1] Fix races in Windows pthread emulation  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: [PATCH v1] Fix races in Windows pthread emulation
List pgsql-hackers
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@gmail.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: COPY FROM ... WHERE fails for negated operators
Next
From: Masahiko Sawada
Date:
Subject: Re: Session in aborted transaction misses effective_wal_level change