<glossterm linkend="glossary-mvcc">MVCC</glossterm>.
     This can be initiated through the use of
     the <command>VACUUM</command> command, but can also be handled automatically
     via <glossterm linkend="glossary-autovacuum">autovacuum</glossterm> processes.
    </para>
    <para>
     For more information, see
     <xref linkend="routine-vacuuming"/> .
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-view">
   <glossterm>View</glossterm>
   <glossdef>
    <para>
     A <glossterm linkend="glossary-relation">relation</glossterm> that is defined by a
     <command>SELECT</command> statement, but has no storage of its own.
     Any time a query references a view, the definition of the view is
     substituted into the query as if the user had typed it as a subquery
     instead of the name of the view.
    </para>
    <para>
     For more information, see
     <xref linkend="sql-createview"/>.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-vm">
   <glossterm>Visibility map (fork)</glossterm>
   <glossdef>
    <para>
     A storage structure that keeps metadata about each data page
     of a table's main fork.  The visibility map entry for
     each page stores two bits: the first one
     (<literal>all-visible</literal>) indicates that all tuples
     in the page are visible to all transactions.  The second one
     (<literal>all-frozen</literal>) indicates that all tuples
     in the page are marked frozen.
    </para>
   </glossdef>
  </glossentry>

  <glossentry>
   <glossterm>WAL</glossterm>
   <glosssee otherterm="glossary-wal" />
  </glossentry>

  <glossentry id="glossary-wal-archiver">
   <glossterm>WAL archiver (process)</glossterm>
   <glossdef>
    <para>
     An <glossterm linkend="glossary-auxiliary-proc">auxiliary process</glossterm>
     which, if enabled, saves copies of
     <glossterm linkend="glossary-wal-file">WAL files</glossterm>
     for the purpose of creating backups or keeping
     <glossterm linkend="glossary-replica">replicas</glossterm> current.
    </para>
    <para>
     For more information, see
     <xref linkend="continuous-archiving"/>.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-wal-file">
   <glossterm>WAL file</glossterm>
   <glossdef>
    <para>
     Also known as <firstterm>WAL segment</firstterm> or
     <firstterm>WAL segment file</firstterm>.
     Each of the sequentially-numbered files that provide storage space for
     <glossterm linkend="glossary-wal">WAL</glossterm>.
     The files are all of the same predefined size
     and are written in sequential order, interspersing changes
     as they occur in multiple simultaneous sessions.
     If the system crashes, the files are read in order, and each of the
     changes is replayed to restore the system to the state it was in
     before the crash.
    </para>
    <para>
     Each WAL file can be released after a
     <glossterm linkend="glossary-checkpoint">checkpoint</glossterm>
     writes all the changes in it to the corresponding data files.
     Releasing the file can be done either by deleting it, or by changing its
     name so that it will be used in the future, which is called
     <firstterm>recycling</firstterm>.
    </para>
    <para>
     For more information, see
     <xref linkend="wal-internals"/>.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-wal-record">
   <glossterm>WAL record</glossterm>
   <glossdef>
    <para>
     A low-level description of an individual data change.
     It contains sufficient information for the data change to be
     re-executed (<firstterm>replayed</firstterm>) in case a system failure
     causes the change to be lost.
     WAL records use a non-printable binary format.
    </para>
    <para>
     For more information, see
     <xref linkend="wal-internals"/>.
    </para>
   </glossdef>
  </glossentry>