database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-10-22 14:32:25 +03:00
Code Activity

Support direct I/O on macOS.

Browse Source 
Macs don't understand O_DIRECT, but they can disable caching with a
separate fcntl() call.  Extend the file opening functions in fd.c to
handle this for us if the caller passes in PG_O_DIRECT.

For now, this affects only WAL data and even then only if you set:

  max_wal_senders=0
  wal_level=minimal

This is not expected to be very useful on its own, but later proposed
patches will make greater use of direct I/O, and it'll be useful for
testing if developers on Macs can see the effects.

Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/CA%2BhUKG%2BADiyyHe0cun2wfT%2BSVnFVqNYPxoO6J9zcZkVO7%2BNGig%40mail.gmail.com
This commit is contained in:
Thomas Munro
2021-07-19 08:52:00 +12:00
parent f157db8622
commit 2dbe890571
4 changed files with 83 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
src/include/access/xlogdefs.h
View File

@@ -64,21 +64,6 @@ typedef uint32 TimeLineID;
*/
typedef uint16 RepOriginId;
/*
* Because O_DIRECT bypasses the kernel buffers, and because we never
* read those buffers except during crash recovery or if wal_level != minimal,
* it is a win to use it in all cases where we sync on each write(). We could
* allow O_DIRECT with fsync(), but it is unclear if fsync() could process
* writes not buffered in the kernel. Also, O_DIRECT is never enough to force
* data to the drives, it merely tries to bypass the kernel cache, so we still
* need O_SYNC/O_DSYNC.
*/
#ifdef O_DIRECT
#define PG_O_DIRECT O_DIRECT
#else
#define PG_O_DIRECT 0
#endif
/*
* This chunk of hackery attempts to determine which file sync methods
* are available on the current platform, and to choose an appropriate