Re: [PATCH] Add native windows on arm64 support

On 2024-09-24 Tu 2:31 PM, Dave Cramer wrote:
>
>
> On Tue, 13 Feb 2024 at 16:28, Dave Cramer <davecramer@postgres.rocks> 
> wrote:
>
>
>
>
>     On Tue, 13 Feb 2024 at 12:52, Andres Freund <andres@anarazel.de>
>     wrote:
>
>         Hi,
>
>         On 2024-02-13 12:49:33 -0500, Dave Cramer wrote:
>         > > I think I might have been on to something - if my human
>         emulation of a
>         > > preprocessor isn't wrong, we'd end up with
>         > >
>         > > #define S_UNLOCK(lock)  \
>         > >         do { _ReadWriteBarrier(); (*(lock)) = 0; } while (0)
>         > >
>         > > on msvc + arm. And that's entirely insufficient -
>         _ReadWriteBarrier() just
>         > > limits *compiler* level reordering, not CPU level
>         reordering.  I think it's
>         > > even insufficient on x86[-64], but it's definitely
>         insufficient on arm.
>         > >
>         > In fact ReadWriteBarrier has been deprecated
>         _ReadWriteBarrier | Microsoft
>         > Learn
>         >
>         <https://learn.microsoft.com/en-us/cpp/intrinsics/readwritebarrier?view=msvc-170>
>
>         I'd just ignore that, that's just pushing towards more modern
>         stuff that's
>         more applicable to C++ than C.
>
>
>         > I did try using atomic_thread_fence as per atomic_thread_fence -
>         > cppreference.com <http://cppreference.com>
>         > <https://en.cppreference.com/w/c/atomic/atomic_thread_fence>
>
>         The semantics of atomic_thread_fence are, uh, very odd.  I'd
>         just use
>         MemoryBarrier().
>
>     #defineS_UNLOCK(lock) \
>     do{ MemoryBarrier(); (*(lock)) =0; } while(0)
>     #endif
>     Has no effect.
>
>     I have no idea if that is what you meant that I should do ?
>
>     Dave
>
>
>
> Revisiting this:
>
> Andrew, can you explain the difference between ninja test (which 
> passes) and what the build farm does. The buildfarm crashes.


The buildfarm client performs these steps:


    meson test -C $pgsql --no-rebuild --suite setup
    meson test -t $meson_test_timeout $jflag -C $pgsql --logbase checklog --print-errorlogs --no-rebuild --suite regress --test-args=--no-locale
    meson test -t $meson_test_timeout $jflag -C $pgsql --print-errorlogs --no-rebuild --logbase checkworld --no-suite setup --no-suite regress
    foreach tested locale: meson test -t $meson_test_timeout $jflag -v -C $pgsql --no-rebuild --print-errorlogs --setup running --suite regress-running --logbase regress-installcheck-$locale


$pgsql is the build root, $jflag is setting the number of jobs


IOW, we do test suite setup, run the core regression tests, run all the 
remaining non-install tests, then run the install tests for each locale.

We don't call ninja directly, but I don't see why that should make a 
difference.


cheers


andrew


--
Andrew Dunstan
EDB:https://www.enterprisedb.com