Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.

Hi,

I see this issue persist when I compile PG v14 beta1 on macOS Apple M1
using macOS 11.1 SDK. Even though the build didn't fail, the execution of
initdb on macOS 10.15 failed with the same error. Here is the snippet of
the build log:

--

> gcc -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Werror=vla -Wendif-labels
> -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv
> -Wno-unused-command-line-argument -g -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk
> -mmacosx-version-min=10.14 -arch x86_64 -arch arm64 -O2 -I. -I.
> -I../../../src/include -I/opt/local/Current/include -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk
> -I/opt/local/20210406/include/libxml2
> -I/opt/local/Current/include/libxml2 -I/opt/local/Current/include
> -I/opt/local/Current/include/openssl/ -c -o backup_manifest.o
> backup_manifest.c
> fd.c:3740:10: warning: 'pwritev' is only available on macOS 11.0 or newer
> [-Wunguarded-availability-new]
> part = pg_pwritev(fd, iov, iovcnt, offset);
> ^~~~~~~~~~
> ../../../../src/include/port/pg_iovec.h:49:20: note: expanded from macro
> 'pg_pwritev'
> #define pg_pwritev pwritev
> ^~~~~~~
> /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/sys/uio.h:104:9:
> note: 'pwritev' has been marked as being introduced in macOS 11.0 here, but
> the deployment target is macOS 10.14.0
> ssize_t pwritev(int, const struct iovec *, int, off_t)
> __DARWIN_NOCANCEL(pwritev) __API_AVAILABLE(macos(11.0), ios(14.0),
> watchos(7.0), tvos(14.0));
> ^
> fd.c:3740:10: note: enclose 'pwritev' in a __builtin_available check to
> silence this warning
> part = pg_pwritev(fd, iov, iovcnt, offset);
> ^~~~~~~~~~
> ../../../../src/include/port/pg_iovec.h:49:20: note: expanded from macro
> 'pg_pwritev'
> #define pg_pwritev pwritev

--

initdb failure:
--

> The database cluster will be initialized with locales
> COLLATE: C
> CTYPE: UTF-8
> MESSAGES: C
> MONETARY: C
> NUMERIC: C
> TIME: C
> The default database encoding has accordingly been set to "UTF8".
> initdb: could not find suitable text search configuration for locale
> "UTF-8"
> The default text search configuration will be set to "simple".
> Data page checksums are disabled.
> creating directory /tmp/data ... ok
> creating subdirectories ... ok
> selecting dynamic shared memory implementation ... posix
> selecting default max_connections ... 100
> selecting default shared_buffers ... 128MB
> selecting default time zone ... Asia/Kolkata
> creating configuration files ... ok
> running bootstrap script ... dyld: lazy symbol binding failed: Symbol not
> found: _pwritev
> Referenced from: /Library/PostgreSQL/14/bin/postgres
> Expected in: /usr/lib/libSystem.B.dylib
> dyld: Symbol not found: _pwritev
> Referenced from: /Library/PostgreSQL/14/bin/postgres
> Expected in: /usr/lib/libSystem.B.dylib
> child process was terminated by signal 6: Abort trap: 6
> initdb: removing data directory "/tmp/data"

--

On Wed, Mar 31, 2021 at 7:49 AM James Hilliard <james(dot)hilliard1(at)gmail(dot)com>
wrote:

> On Tue, Mar 30, 2021 at 7:51 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > > Personally I'm mostly concerned about making it easy for new
> > > contributors to get a working dev system going on a super common
> > > platform without dealing with hard-to-diagnose errors, than people who
> > > actually want a different target as a deliberate choice. Do I
> > > understand correctly that there a period of time each year when major
> > > upgrades come out of sync and lots of people finish up running a
> > > toolchain and OS with this problem for a while due to the default
> > > target not matching? If so I wonder if other projects are running
> > > into this with AC_REPLACE_FUNCS and what they're doing.
> >
> > Yeah, we've seen this happen at least a couple of times, though
> > it was only during this past cycle that we (I anyway) entirely
> > understood what was happening.
> >
> > The patches we committed in January (4823621db, 9d23c15a0, 50bebc1ae)
> > to improve our PG_SYSROOT selection heuristics should theoretically
> > improve the situation ... though I admit I won't have a lot of
> > confidence in them till we've been through a couple more rounds of
> > asynchronous-XCode-and-macOS releases. Still, I feel that we
> > ought to leave that code alone until we see how it does.
>
> I mean, we know that it will still break under a number of common
> circumstances so I think we should be fixing the root cause(improper
> detection of target deployment API availability in probes) in some
> way as this will probably continue to be an issue otherwise, we already
> know that improving PG_SYSROOT selection can not fix the root issue
> but rather tries to workaround it in a way that is pretty much guaranteed
> to be brittle.
>
> Is there any approach to fixing the root cause of this issue that you think
> would be acceptable?
>
> >
> > regards, tom lane
>
>
>

--
Sandeep Thakkar