Hi, Thank you for working on this!
On Fri, 24 Jul 2026 at 10:07, Harrison Booth <[email protected]> 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. > The mutex initialization path used InterlockedExchange to set initstate to > 2. A waiting thread could therefore change the fully initialized state from > 1 back to 2. pthread_mutex_unlock would then see a state other than 1, > return EINVAL, and leave the critical section locked. I tried to understand the problem and the related Windows thread functions, please correct my understanding: 1- In pthread_mutex_lock(), calling InterlockedExchange(&mp->initstate, 2) writes unconditionally, clobbering an initialized state 1 back to 2. 2- The thread enters the critical section while mp->initstate = 2. 3- Later, when pthread_mutex_unlock() is called, if (mp->initstate != 1) evaluates to true, causing the function to return EINVAL without releasing the underlying critical section, leading to a deadlock. And your patch fixes this problem with InterlockedCompareExchange(&mp->initstate, 2, 0), because now you check the initial value so that you can't overwrite 1 with 2. [1] https://github.com/nbyavuz/postgres/actions/runs/32351446950/job/96371608653 -- Regards, Nazir Bilal Yavuz Microsoft
