| 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
| 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 |