On Sat, Aug 17, 2024 at 6:58 AM Peter Eisentraut <pe...@eisentraut.org> wrote: > What to do about the order of the symbols and include files. I threw > something into src/include/port/darwin.h, but I'm not sure if that's > good. Alternatively, we could not use __darwin__ but instead the more > standard and predefined defined(__APPLE__) && defined(__MACH__).
Hmm. fd.h and fd.c test for F_NOCACHE, which is pretty closely related. Now I'm wondering why we actually need this in pg_config_manual.h at all. Who would turn it off at compile time, and why would they not be satisfied with setting relevant GUCs to 0? Can we just teach fd.h to define USE_PREFETCH if defined(POSIX_FADV_WILLNEED) || defined(F_RDADVISE)? (I have also thought multiple times about removing the configure probes for F_FULLFSYNC, and just doing #ifdef. Oh, that's in my patch for CF #4453.) > How to document it. The current documentation makes references mainly > to the availability of posix_fadvise(). That seems quite low-level. > How could a user of a prepared package even find out about that? Should > we just say "requires OS support" (kind of like I did here) and you can > query the effective state by looking at the *_io_concurrency settings? > Or do we need a read-only parameter that shows whether prefetch support > exists (kind of along the lines of huge pages)? I think that's fine. I don't really like the word "prefetch", could mean many different things. What about "requires OS support for issuing read-ahead advice", which uses a word that appears in both of those interfaces? And yeah the GUCs being nailed to zero means you don't have it. > (There is also the possibility that we provide an implementation of > posix_fadvise() for macOS that wraps the platform-specific code in this > patch. And then Apple could just take that. ;-) ) Yeah might be simpler... as long as we make sure that we test for having the function AND the relevant POSIX_FADV_xxx in places, which I see that we do.
