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

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.
Дата
Msg-id CA+hUKGK6jGpC0dvkWxGDeuMtJo8qhN-a9Dmd40Esnovq7N=eBQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.  (Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>)
Ответы Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
On Mon, Jun 21, 2021 at 4:32 PM Sandeep Thakkar
<sandeep.thakkar@enterprisedb.com> wrote:
> Do we see any solution to this issue? or using the older SDK is the way to go?

> On Thu, May 20, 2021 at 2:04 PM Dave Page <dpage@pgadmin.org> wrote:
>> The ability to target older releases with a newer SDK is essential for packages such as the EDB PostgreSQL
installersand the pgAdmin community installers. It's very difficult (sometimes impossible) to get older OS versions on
newmachines now - Apple make it very hard to download old versions of macOS (some can be found, others not), and they
won'talways work on newer hardware anyway so it's really not feasible to have all the build machines running the oldest
versionthat needs to be supported. 
>>
>> FYI, the pgAdmin and PG installer buildfarms have -mmacosx-version-min=10.12 in CFLAGS etc. to handle this, which is
synonymouswith MACOSX_DEPLOYMENT_TARGET. We've been successfully building packages that way for a decade or more. 

I'm not personally against the proposed change.  I'll admit there is
something annoying about Apple's environment working in a way that
doesn't suit traditional configure macros that have been the basis of
portable software for a few decades, but when all's said and done,
configure is a Unix wars era way to make things work across all the
Unixes, and most of them are long gone, configure itself is on the way
out, and Apple's still here, so...

On a more practical note, rereading Tom's objection and Dave's
counter-objection, I'm left wondering if people would be happy with a
manual control for this, something you can pass to configure to stop
it from using pwritev/preadv even if detected.  That would at least
localise the effects, avoiding the sorts of potential unintended
consequences Tom mentioned.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Re: Optionally automatically disable logical replication subscriptions on error
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: Optionally automatically disable logical replication subscriptions on error