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+hUKGK85Uqfwuxo=TjPnXXsfsvMv3YG_fAVc9yJmpOEEQT1gw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.
Список pgsql-hackers
On Tue, Jul 13, 2021 at 7:39 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
> On 06.07.21 22:34, Tom Lane wrote:
> > 2. We'd really like to use preadv/pwritev where available.
>
> A couple of things that I haven't seen made clear in this thread yet:
>
> - Where is the availability boundary for preadv/pwritev on macOS?

Big Sur (11) added these.

> - What is the impact of having vs. not having these functions?

The impact is very low.  PG14 only uses pg_pwritev() to fill in new
WAL files as a sort of a warm-up exercise, and it'll happy use lseek()
+ writev() instead.  In future proposals they would be used to do
general scatter/gather I/O for data files as I showed in another
email[1], but that's way off and far from certain, and even then it's
just a matter of avoiding an lseek() call on vectored I/O.  As for how
long Apple will support 10.15, they don't seem to publish a roadmap,
but people seem to say the pattern would have security updates ending
some time in 2022 (?).  I don't know if EDB targets macOS older than
Apple supports, but given the very low impact and all these time
frames it seems OK  to just not use the new syscalls on macOS for a
couple more years at least, whatever mechanism is chosen for that.

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.  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.

[1] https://www.postgresql.org/message-id/CA%2BhUKGK-563RQWQQF4NLajbQk%2B65gYHdb1q%3D7p3Ob0Uvrxoa9g%40mail.gmail.com



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [PATCH] Don't block HOT update by BRIN index
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: [PATCH] Don't block HOT update by BRIN index