the event of a power failure or system crash. Thus it

is only advisable to turn off <varname>fsync</varname> if

<varname>fsync</varname> include the initial loading of a new

for processing a batch of data after which the database

will be thrown away and recreated,

or for a read-only database clone which

<literal>fsync</> (call <function>fsync()</> at each commit)

<literal>fsync_writethrough</> (call <function>fsync()</> at each commit, forcing write-through of any disk write cache)

Not all of these choices are available on all platforms.

by the platform, except that <literal>fdatasync</> is the default on

Linux. The default is not necessarily ideal; it might be

microseconds, before a transaction attempts to

flush the WAL buffer out to disk. A nonzero delay can allow more

transactions to be committed with only one flush operation, if

commit record.

The default <varname>commit_delay</> is zero (no delay).

Since all pending commit data will be written at every flush

regardless of this setting, it is rare that adding delay

by increasing this parameter will actually improve performance.

While forcing data to the disk platters periodically might seem like

<firstterm>battery-backup units</> (<acronym>BBU</>s), meaning

exist for write-back drive caches as for disk controller

to have write-back caches that will not survive a power failure. Many

solid-state drives (SSD) also have volatile write-back caches.

Use <command>sdparm --get=WCE</command> to check

<literal>open_datasync</> (the default), write caching can be disabled

by unchecking <literal>My Computer\Open\<replaceable>disk drive</>\Properties\Hardware\Properties\Policies\Enable write caching on the disk</>.

Alternatively, set <varname>wal_sync_method</varname> to

<literal>fsync</> or <literal>fsync_writethrough</>, which prevent

write caching.

On <productname>Mac OS X</productname>, write caching can be prevented by

Recent SATA drives (those following <acronym>ATAPI-6</> or later)

offer a drive cache flush command (<command>FLUSH CACHE EXT</>),

while SCSI drives have long supported a similar command

<command>SYNCHRONIZE CACHE</>. These commands are not directly

accessible to <productname>PostgreSQL</>, but some file systems

(e.g., <acronym>ZFS</>, <acronym>ext4</>) can use them to flush

data to the platters on write-back-enabled drives. Unfortunately, such

file systems behave suboptimally when combined with battery-backup unit

command forces all data from the controller cache to the disks,

eliminating much of the benefit of the BBU. You can run the utility

of the BBU can be regained by turning off write barriers in

remains functional; a faulty battery can potentially lead to data loss.

If you use SSDs, be aware that many of these do not honor cache flush

commands by default.

When a write request arrives at the drive, it might be for some multiple

of 512 bytes (<productname>PostgreSQL</> typically writes 8192 bytes, or

16 sectors, at a time), and the process of writing could fail due

written while others were not. To guard against such failures,

restore partially-written pages from WAL. If you have a battery-backed disk

(e.g., ZFS), you can safely turn off this page imaging by turning off the

/* #if is to skip the sync_method test if there's no need for it */

#if defined(HAVE_FSYNC_WRITETHROUGH) && !defined(FSYNC_WRITETHROUGH_IS_FSYNC)

if (sync_method == SYNC_METHOD_FSYNC_WRITETHROUGH)

return pg_fsync_writethrough(fd);

return pg_fsync_no_writethrough(fd);

# fdatasync (default on Linux)

#if defined(PLATFORM_DEFAULT_SYNC_METHOD)

#define DEFAULT_SYNC_METHOD PLATFORM_DEFAULT_SYNC_METHOD

#elif defined(OPEN_DATASYNC_FLAG)

#define PLATFORM_DEFAULT_SYNC_METHOD SYNC_METHOD_FDATASYNC

#define fsync(fd) _commit(fd)

#define HAVE_FSYNC_WRITETHROUGH

#define FSYNC_WRITETHROUGH_IS_FSYNC