Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.
От | Tom Lane |
---|---|
Тема | Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX. |
Дата | |
Msg-id | 1751169.1625605107@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX. (James Hilliard <james.hilliard1@gmail.com>) |
Список | pgsql-hackers |
James Hilliard <james.hilliard1@gmail.com> writes: > On Tue, Jul 6, 2021 at 2:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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. > Maybe we just need to do something like this?: > https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg06499.html Hm. I don't trust __builtin_available too much --- does it exist on really old macOS? dlsym() seems less likely to create problems in that respect. Of course, if there are scenarios where __builtin_available knows that the symbol is available but doesn't work, then we might have to use it. In any case, I don't like their superstructure around the probe. What I'd prefer is a function pointer that initially points to the probe code, and then we change it to point at either pwritev or the pg_pwritev emulation. Certainly failing with ENOSYS is exactly what *not* to do. regards, tom lane
В списке pgsql-hackers по дате отправления: