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: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(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-12 22:03:41
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> Clearly there is a more general question though, which is "should we
> buy into Apple's ABI management system or not", and I don't have a
> strong opinion on that.

Well, I definitely don't wish to clutter our core code with any
explicit dependencies on MACOSX_DEPLOYMENT_TARGET. However,
if we can work around the issue by switching from AC_REPLACE_FUNCS
to AC_CHECK_DECLS, maybe we should just do that and quit arguing
about it. It seems like there's not a lot of enthusiasm for my idea
about installing a run-time probe, so I won't push for that.

> One thing I do know is that
> pthread_barrier_XXX changed from option to required in a recentish
> POSIX update so I expect the question to come up again eventually.

Yeah, we can expect that the issue will arise again, which is why
I was so unhappy with the rather-invasive patches we started with.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2021-07-12 22:08:22 Re: proposal: possibility to read dumped table's name from file
Previous Message Stephen Frost 2021-07-12 21:30:49 Re: What are exactly bootstrap processes, auxiliary processes, standalone backends, normal backends(user sessions)?