Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX. - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.
Date
Msg-id CA+hUKGJ9Fsy3Hdgs8BpgBd+J06qo9=4LdGBK5sWxzBt08fENgg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.  (James Hilliard <james.hilliard1@gmail.com>)
Responses Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.
List pgsql-hackers
On Tue, Mar 30, 2021 at 6:37 AM James Hilliard
<james.hilliard1@gmail.com> wrote:
> Should it work if I just attach it to the thread like this?

Yes.  It automatically tries patches that are attached to threads that
are registered on commitfest.postgresql.org on 4 OSes, and we can see
that it succeeded, and we can inspect the configure output and see
that only the two clang-based systems detected and used the new
unguarded-availability-new flags and used them.

This should be alphabetised better:

         HAVE_PREAD                  => undef,
-        HAVE_PREADV                 => undef,
+        HAVE_DECL_PREADV            => 0,
         HAVE_PSTAT                  => undef,

So the question here is really:  do we want to support Apple cross-SDK
builds, in our configure scripts?  It costs very little to switch from
traditional "does-this-symbol-exist?" tests to testing declarations,
so no objections here.

I doubt people will remember to do this for other new syscall probes
though, so it might be a matter of discussing it case-by-case when a
problem shows up.  For example, I recently added another new test,
specifically targeting macOS: pthread_barrier_wait.  One day they
might add it to libSystem and we might need to tweak that one
similarly.



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: psql lacking clearerr()
Next
From: Arseny Sher
Date:
Subject: Flaky vacuum truncate test in reloptions.sql