begriffs open source - ai-pg/blob - full-docs/html/wal-internals.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>28.6. WAL Internals</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="wal-configuration.html" title="28.5. WAL Configuration" /><link rel="next" href="logical-replication.html" title="Chapter 29. Logical Replication" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">28.6. WAL Internals</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="wal-configuration.html" title="28.5. WAL Configuration">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="wal.html" title="Chapter 28. Reliability and the Write-Ahead Log">Up</a></td><th width="60%" align="center">Chapter 28. Reliability and the Write-Ahead Log</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="logical-replication.html" title="Chapter 29. Logical Replication">Next</a></td></tr></table><hr /></div><div class="sect1" id="WAL-INTERNALS"><div class="titlepage"><div><div><h2 class="title" style="clear: both">28.6. WAL Internals <a href="#WAL-INTERNALS" class="id_link">#</a></h2></div></div></div><a id="id-1.6.15.8.2" class="indexterm"></a><p>
   3    <acronym class="acronym">WAL</acronym> is automatically enabled; no action is
   4    required from the administrator except ensuring that the
   5    disk-space requirements for the <acronym class="acronym">WAL</acronym> files are met,
   6    and that any necessary tuning is done (see <a class="xref" href="wal-configuration.html" title="28.5. WAL Configuration">Section 28.5</a>).
   7   </p><p>
   8    <acronym class="acronym">WAL</acronym> records are appended to the <acronym class="acronym">WAL</acronym>
   9    files as each new record is written. The insert position is described by
  10    a Log Sequence Number (<acronym class="acronym">LSN</acronym>) that is a byte offset into
  11    the WAL, increasing monotonically with each new record.
  12    <acronym class="acronym">LSN</acronym> values are returned as the datatype
  13    <a class="link" href="datatype-pg-lsn.html" title="8.20. pg_lsn Type"><code class="type">pg_lsn</code></a>. Values can be
  14    compared to calculate the volume of <acronym class="acronym">WAL</acronym> data that
  15    separates them, so they are used to measure the progress of replication
  16    and recovery.
  17   </p><p>
  18    <acronym class="acronym">WAL</acronym> files are stored in the directory
  19    <code class="filename">pg_wal</code> under the data directory, as a set of
  20    segment files, normally each 16 MB in size (but the size can be changed
  21    by altering the <code class="option">--wal-segsize</code> <span class="application">initdb</span> option).  Each segment is
  22    divided into pages, normally 8 kB each (this size can be changed via the
  23    <code class="option">--with-wal-blocksize</code> configure option).  The WAL record headers
  24    are described in <code class="filename">access/xlogrecord.h</code>; the record
  25    content is dependent on the type of event that is being logged.  Segment
  26    files are given ever-increasing numbers as names, starting at
  27    <code class="filename">000000010000000000000001</code>.  The numbers do not wrap,
  28    but it will take a very, very long time to exhaust the
  29    available stock of numbers.
  30   </p><p>
  31    It is advantageous if the WAL is located on a different disk from the
  32    main database files.  This can be achieved by moving the
  33    <code class="filename">pg_wal</code> directory to another location (while the server
  34    is shut down, of course) and creating a symbolic link from the
  35    original location in the main data directory to the new location.
  36   </p><p>
  37    The aim of <acronym class="acronym">WAL</acronym> is to ensure that the log is
  38    written before database records are altered, but this can be subverted by
  39    disk drives<a id="id-1.6.15.8.7.2" class="indexterm"></a> that falsely report a
  40    successful write to the kernel,
  41    when in fact they have only cached the data and not yet stored it
  42    on the disk.  A power failure in such a situation might lead to
  43    irrecoverable data corruption.  Administrators should try to ensure
  44    that disks holding <span class="productname">PostgreSQL</span>'s
  45    <acronym class="acronym">WAL</acronym> files do not make such false reports.
  46    (See <a class="xref" href="wal-reliability.html" title="28.1. Reliability">Section 28.1</a>.)
  47   </p><p>
  48    After a checkpoint has been made and the WAL flushed, the
  49    checkpoint's position is saved in the file
  50    <code class="filename">pg_control</code>. Therefore, at the start of recovery,
  51    the server first reads <code class="filename">pg_control</code> and
  52    then the checkpoint record; then it performs the REDO operation by
  53    scanning forward from the WAL location indicated in the checkpoint
  54    record.  Because the entire content of data pages is saved in the
  55    WAL on the first page modification after a checkpoint (assuming
  56    <a class="xref" href="runtime-config-wal.html#GUC-FULL-PAGE-WRITES">full_page_writes</a> is not disabled), all pages
  57    changed since the checkpoint will be restored to a consistent
  58    state.
  59   </p><p>
  60    To deal with the case where <code class="filename">pg_control</code> is
  61    corrupt, we should support the possibility of scanning existing WAL
  62    segments in reverse order — newest to oldest — in order to find the
  63    latest checkpoint.  This has not been implemented yet.
  64    <code class="filename">pg_control</code> is small enough (less than one disk page)
  65    that it is not subject to partial-write problems, and as of this writing
  66    there have been no reports of database failures due solely to the inability
  67    to read <code class="filename">pg_control</code> itself.  So while it is
  68    theoretically a weak spot, <code class="filename">pg_control</code> does not
  69    seem to be a problem in practice.
  70   </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="wal-configuration.html" title="28.5. WAL Configuration">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="wal.html" title="Chapter 28. Reliability and the Write-Ahead Log">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="logical-replication.html" title="Chapter 29. Logical Replication">Next</a></td></tr><tr><td width="40%" align="left" valign="top">28.5. <acronym class="acronym">WAL</acronym> Configuration </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> Chapter 29. Logical Replication</td></tr></table></div></body></html>