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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: James Hilliard <james(dot)hilliard1(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: [PATCH 1/1] Fix detection of pwritev support for OSX.
Date: 2021-01-19 15:57:25
Message-ID: 480660.1611071845@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

James Hilliard <james(dot)hilliard1(at)gmail(dot)com> writes:
> On Tue, Jan 19, 2021 at 8:27 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> We already dealt with that by not selecting an SDK newer than the
>> underlying OS (see 4823621db).

> Tried that, doesn't work, not even sure how it could possibly fix this
> issue at all,

It worked for me and for Sergey, so we need to figure out what's different
about your setup. What do you get from "xcrun --show-sdk-path" and
"xcrun --sdk macosx --show-sdk-path"? What have you got under
/Library/Developer/CommandLineTools/SDKs ?

> this can not be fixed properly by selecting a specific SDK version
> alone, it's the symbols valid for a specific target deployment version
> that matters here.

I don't think I believe that argument. As a counterexample, supposing
that somebody were intentionally cross-compiling on an older OSX platform
but using a newer SDK, shouldn't they get an executable suited to the
SDK's target version?

(I realize that Apple thinks we ought to handle that through run-time
not compile-time adaptation, but I have no interest in going there.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2021-01-19 16:01:05 Re: POC: postgres_fdw insert batching
Previous Message Tom Lane 2021-01-19 15:45:35 Re: Use boolean array for nulls parameters