Home • Explore • Blog • CI
☰



postgresql
15th chunk of `doc/src/sgml/wal.sgml`
bfdb5b5b485524778480f6ce273f31909054156b7a8b64430000000100000b79
 <literal>open_sync</literal>,
   a write operation in <function>XLogWrite</function> guarantees to sync written
   WAL data to disk and <function>issue_xlog_fsync</function> does nothing.
   If <varname>wal_sync_method</varname> is either <literal>fdatasync</literal>,
   <literal>fsync</literal>, or <literal>fsync_writethrough</literal>,
   the write operation moves WAL buffers to kernel cache and
   <function>issue_xlog_fsync</function> syncs them to disk. Regardless
   of the setting of <varname>track_wal_io_timing</varname>, the number
   of times <function>XLogWrite</function> writes and
   <function>issue_xlog_fsync</function> syncs WAL data to disk are also
   counted as <varname>writes</varname> and <varname>fsyncs</varname>
   in <structname>pg_stat_io</structname> for the <varname>object</varname>
   <literal>wal</literal>, respectively.
  </para>

  <para>
   The <xref linkend="guc-recovery-prefetch"/> parameter can be used to reduce
   I/O wait times during recovery by instructing the kernel to initiate reads
   of disk blocks that will soon be needed but are not currently in
   <productname>PostgreSQL</productname>'s buffer pool.
   The <xref linkend="guc-maintenance-io-concurrency"/> and
   <xref linkend="guc-wal-decode-buffer-size"/> settings limit prefetching
   concurrency and distance, respectively.  By default, it is set to
   <literal>try</literal>, which enables the feature on systems that support
   issuing read-ahead advice.
  </para>
 </sect1>

 <sect1 id="wal-internals">
  <title>WAL Internals</title>

  <indexterm zone="wal-internals">
   <primary>LSN</primary>
  </indexterm>

  <para>
   <acronym>WAL</acronym> is automatically enabled; no action is
   required from the administrator except ensuring that the
   disk-space requirements for the <acronym>WAL</acronym> files are met,
   and that any necessary tuning is done (see <xref
   linkend="wal-configuration"/>).
  </para>

  <para>
   <acronym>WAL</acronym> records are appended to the <acronym>WAL</acronym>
   files as each new record is written. The insert position is described by
   a Log Sequence Number (<acronym>LSN</acronym>) that is a byte offset into
   the WAL, increasing monotonically with each new record.
   <acronym>LSN</acronym> values are returned as the datatype
   <link linkend="datatype-pg-lsn"><type>pg_lsn</type></link>. Values can be
   compared to calculate the volume of <acronym>WAL</acronym> data that
   separates them, so they are used to measure the progress of replication
   and recovery.
  </para>

  <para>
   <acronym>WAL</acronym> files are stored in the directory
   <filename>pg_wal</filename> under the data directory, as a set of
   segment files, normally each 16 MB in size (but the size can be changed
   by altering the <option>--wal-segsize</option> <application>initdb</application> option).  Each segment is
   divided into pages, normally 8 kB each (this size can be changed
Title: WAL Internals and Configuration
Summary
Write-Ahead Logging (WAL) in PostgreSQL is automatically enabled and requires ensuring sufficient disk space and tuning as needed, with parameters like recovery_prefetch and maintenance_io_concurrency controlling I/O behavior, and WAL records are stored in segment files with a monotonically increasing Log Sequence Number (LSN) describing the insert position.