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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Sandeep Thakkar <sandeep(dot)thakkar(at)enterprisedb(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, James Hilliard <james(dot)hilliard1(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru>
Subject: Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.
Date: 2021-07-06 20:34:09
Message-ID: 1749830.1625603649@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> I think this change is perfectly appropriate (modulo some small cleanups).

I think there are a couple of issues here.

1. People who are already using MACOSX_DEPLOYMENT_TARGET to control
their builds would like to keep on doing so, but the AC_CHECK_FUNCS
probe doesn't work with that. James' latest patch seems like a
reasonable fix for that (it's a lot less invasive than where we
started from). There is a worry about side-effects on other
platforms, but I don't see an answer to that that's better than
"throw it on the buildfarm and see if anything breaks".

However ...

2. We'd really like to use preadv/pwritev where available. I
maintain that MACOSX_DEPLOYMENT_TARGET is not only not the right
approach to that, but it's actually counterproductive. It forces
you to build for the lowest common denominator, ie the oldest macOS
release you want to support. Even when running on a release that
has pwritev, your build will never use it.

As far as I can tell, the only way to really deal with #2 is to
perform a runtime dlsym() probe to see whether pwritev exists, and
then fall back to our src/port/ implementation if not. This does
not look particularly hard (especially since the lookup code only
needs to work on macOS), though I admit I've not tried to code it.

What's unclear to me at the moment is whether #1 and #2 interact,
ie is there still any point in changing configure's probes if
we put in a runtime check on Darwin? I think that we might want
to pay no attention to what the available header files say about
pwritev, as long as we can get the correct 'struct iovec'
declaration from them.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2021-07-06 20:49:07 Re: rand48 replacement
Previous Message Dean Rasheed 2021-07-06 20:10:02 Re: Using COPY FREEZE in pgbench