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

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Harrison Booth <harrisontbooth(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH v1] Fix races in Windows pthread emulation
Date: 2026-10-05 18:00:00
Message-ID: 9073309f-1805-49a4-87b7-dbdd010cebd4@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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(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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-10-05 18:01:50 Re: Session in aborted transaction misses effective_wal_level change
Previous Message Tom Lane 2026-10-05 17:48:44 Re: COPY FROM ... WHERE fails for negated operators