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

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.

</para>

<para>

These caches can typically be disabled; however, the method for doing

this varies by operating system and drive type:

</para>

<itemizedlist>

<listitem>

<para>

On <productname>Linux</>, IDE drives can be queried using

<command>hdparm -I</command>; write caching is enabled if there is

a <literal>*</> next to <literal>Write cache</>. <command>hdparm -W</>

can be used to turn off write caching. SCSI drives can be queried

using <ulink url="http://sg.danny.cz/sg/sdparm.html"><application>sdparm</></ulink>.

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

whether the write cache is enabled and <command>sdparm --clear=WCE</>

to disable it.

</para>

</listitem>

<listitem>

<para>

On <productname>FreeBSD</>, IDE drives can be queried using

<command>atacontrol</command>, and SCSI drives using

<command>sdparm</command>.

</para>

</listitem>

<listitem>

<para>

On <productname>Solaris</>, the disk write cache is controlled by

<ulink url="http://www.sun.com/bigadmin/content/submitted/format_utility.jsp"><literal>format -e</></ulink>.

(The Solaris <acronym>ZFS</> file system is safe with disk write-cache

enabled because it issues its own disk cache flush commands.)

</para>

</listitem>

<listitem>

<para>

On <productname>Windows</>, if <varname>wal_sync_method</> is

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

</para>

</listitem>

<listitem>

<para>

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

setting <varname>wal_sync_method</> to <literal>fsync_writethrough</>.

</para>

</listitem>

</itemizedlist>

<para>

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