<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!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>68.1. Database File Layout</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="storage.html" title="Chapter 68. Database Physical Storage" /><link rel="next" href="storage-toast.html" title="68.2. TOAST" /></head><body><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">68.1. Database File Layout</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="storage.html" title="Chapter 68. Database Physical Storage">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="storage.html" title="Chapter 68. Database Physical Storage">Up</a></td><th width="60%" align="center">Chapter 68. Database Physical Storage</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 11.5 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="storage-toast.html" title="68.2. TOAST">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="STORAGE-FILE-LAYOUT"><div class="titlepage"><div><div><h2 class="title" style="clear: both">68.1. Database File Layout</h2></div></div></div><p> This section describes the storage format at the level of files and directories. </p><p> Traditionally, the configuration and data files used by a database cluster are stored together within the cluster's data directory, commonly referred to as <code class="varname">PGDATA</code> (after the name of the environment variable that can be used to define it). A common location for <code class="varname">PGDATA</code> is <code class="filename">/var/lib/pgsql/data</code>. Multiple clusters, managed by different server instances, can exist on the same machine. </p><p> The <code class="varname">PGDATA</code> directory contains several subdirectories and control files, as shown in <a class="xref" href="storage-file-layout.html#PGDATA-CONTENTS-TABLE" title="Table 68.1. Contents of PGDATA">Table 68.1</a>. In addition to these required items, the cluster configuration files <code class="filename">postgresql.conf</code>, <code class="filename">pg_hba.conf</code>, and <code class="filename">pg_ident.conf</code> are traditionally stored in <code class="varname">PGDATA</code>, although it is possible to place them elsewhere. </p><div class="table" id="PGDATA-CONTENTS-TABLE"><p class="title"><strong>Table 68.1. Contents of <code class="varname">PGDATA</code></strong></p><div class="table-contents"><table class="table" summary="Contents of PGDATA" border="1"><colgroup><col /><col /></colgroup><thead><tr><th> Item </th><th>Description</th></tr></thead><tbody><tr><td><code class="filename">PG_VERSION</code></td><td>A file containing the major version number of <span class="productname">PostgreSQL</span></td></tr><tr><td><code class="filename">base</code></td><td>Subdirectory containing per-database subdirectories</td></tr><tr><td><code class="filename">current_logfiles</code></td><td>File recording the log file(s) currently written to by the logging collector</td></tr><tr><td><code class="filename">global</code></td><td>Subdirectory containing cluster-wide tables, such as <code class="structname">pg_database</code></td></tr><tr><td><code class="filename">pg_commit_ts</code></td><td>Subdirectory containing transaction commit timestamp data</td></tr><tr><td><code class="filename">pg_dynshmem</code></td><td>Subdirectory containing files used by the dynamic shared memory subsystem</td></tr><tr><td><code class="filename">pg_logical</code></td><td>Subdirectory containing status data for logical decoding</td></tr><tr><td><code class="filename">pg_multixact</code></td><td>Subdirectory containing multitransaction status data (used for shared row locks)</td></tr><tr><td><code class="filename">pg_notify</code></td><td>Subdirectory containing LISTEN/NOTIFY status data</td></tr><tr><td><code class="filename">pg_replslot</code></td><td>Subdirectory containing replication slot data</td></tr><tr><td><code class="filename">pg_serial</code></td><td>Subdirectory containing information about committed serializable transactions</td></tr><tr><td><code class="filename">pg_snapshots</code></td><td>Subdirectory containing exported snapshots</td></tr><tr><td><code class="filename">pg_stat</code></td><td>Subdirectory containing permanent files for the statistics subsystem</td></tr><tr><td><code class="filename">pg_stat_tmp</code></td><td>Subdirectory containing temporary files for the statistics subsystem</td></tr><tr><td><code class="filename">pg_subtrans</code></td><td>Subdirectory containing subtransaction status data</td></tr><tr><td><code class="filename">pg_tblspc</code></td><td>Subdirectory containing symbolic links to tablespaces</td></tr><tr><td><code class="filename">pg_twophase</code></td><td>Subdirectory containing state files for prepared transactions</td></tr><tr><td><code class="filename">pg_wal</code></td><td>Subdirectory containing WAL (Write Ahead Log) files</td></tr><tr><td><code class="filename">pg_xact</code></td><td>Subdirectory containing transaction commit status data</td></tr><tr><td><code class="filename">postgresql.auto.conf</code></td><td>A file used for storing configuration parameters that are set by <code class="command">ALTER SYSTEM</code></td></tr><tr><td><code class="filename">postmaster.opts</code></td><td>A file recording the command-line options the server was last started with</td></tr><tr><td><code class="filename">postmaster.pid</code></td><td>A lock file recording the current postmaster process ID (PID), cluster data directory path, postmaster start timestamp, port number, Unix-domain socket directory path (empty on Windows), first valid listen_address (IP address or <code class="literal">*</code>, or empty if not listening on TCP), and shared memory segment ID (this file is not present after server shutdown)</td></tr></tbody></table></div></div><br class="table-break" /><p> For each database in the cluster there is a subdirectory within <code class="varname">PGDATA</code><code class="filename">/base</code>, named after the database's OID in <code class="structname">pg_database</code>. This subdirectory is the default location for the database's files; in particular, its system catalogs are stored there. </p><p> Each table and index is stored in a separate file. For ordinary relations, these files are named after the table or index's <em class="firstterm">filenode</em> number, which can be found in <code class="structname">pg_class</code>.<code class="structfield">relfilenode</code>. But for temporary relations, the file name is of the form <code class="literal">t<em class="replaceable"><code>BBB</code></em>_<em class="replaceable"><code>FFF</code></em></code>, where <em class="replaceable"><code>BBB</code></em> is the backend ID of the backend which created the file, and <em class="replaceable"><code>FFF</code></em> is the filenode number. In either case, in addition to the main file (a/k/a main fork), each table and index has a <em class="firstterm">free space map</em> (see <a class="xref" href="storage-fsm.html" title="68.3. Free Space Map">Section 68.3</a>), which stores information about free space available in the relation. The free space map is stored in a file named with the filenode number plus the suffix <code class="literal">_fsm</code>. Tables also have a <em class="firstterm">visibility map</em>, stored in a fork with the suffix <code class="literal">_vm</code>, to track which pages are known to have no dead tuples. The visibility map is described further in <a class="xref" href="storage-vm.html" title="68.4. Visibility Map">Section 68.4</a>. Unlogged tables and indexes have a third fork, known as the initialization fork, which is stored in a fork with the suffix <code class="literal">_init</code> (see <a class="xref" href="storage-init.html" title="68.5. The Initialization Fork">Section 68.5</a>). </p><div class="caution"><h3 class="title">Caution</h3><p> Note that while a table's filenode often matches its OID, this is <span class="emphasis"><em>not</em></span> necessarily the case; some operations, like <code class="command">TRUNCATE</code>, <code class="command">REINDEX</code>, <code class="command">CLUSTER</code> and some forms of <code class="command">ALTER TABLE</code>, can change the filenode while preserving the OID. Avoid assuming that filenode and table OID are the same. Also, for certain system catalogs including <code class="structname">pg_class</code> itself, <code class="structname">pg_class</code>.<code class="structfield">relfilenode</code> contains zero. The actual filenode number of these catalogs is stored in a lower-level data structure, and can be obtained using the <code class="function">pg_relation_filenode()</code> function. </p></div><p> When a table or index exceeds 1 GB, it is divided into gigabyte-sized <em class="firstterm">segments</em>. The first segment's file name is the same as the filenode; subsequent segments are named filenode.1, filenode.2, etc. This arrangement avoids problems on platforms that have file size limitations. (Actually, 1 GB is just the default segment size. The segment size can be adjusted using the configuration option <code class="option">--with-segsize</code> when building <span class="productname">PostgreSQL</span>.) In principle, free space map and visibility map forks could require multiple segments as well, though this is unlikely to happen in practice. </p><p> A table that has columns with potentially large entries will have an associated <em class="firstterm">TOAST</em> table, which is used for out-of-line storage of field values that are too large to keep in the table rows proper. <code class="structname">pg_class</code>.<code class="structfield">reltoastrelid</code> links from a table to its <acronym class="acronym">TOAST</acronym> table, if any. See <a class="xref" href="storage-toast.html" title="68.2. TOAST">Section 68.2</a> for more information. </p><p> The contents of tables and indexes are discussed further in <a class="xref" href="storage-page-layout.html" title="68.6. Database Page Layout">Section 68.6</a>. </p><p> Tablespaces make the scenario more complicated. Each user-defined tablespace has a symbolic link inside the <code class="varname">PGDATA</code><code class="filename">/pg_tblspc</code> directory, which points to the physical tablespace directory (i.e., the location specified in the tablespace's <code class="command">CREATE TABLESPACE</code> command). This symbolic link is named after the tablespace's OID. Inside the physical tablespace directory there is a subdirectory with a name that depends on the <span class="productname">PostgreSQL</span> server version, such as <code class="literal">PG_9.0_201008051</code>. (The reason for using this subdirectory is so that successive versions of the database can use the same <code class="command">CREATE TABLESPACE</code> location value without conflicts.) Within the version-specific subdirectory, there is a subdirectory for each database that has elements in the tablespace, named after the database's OID. Tables and indexes are stored within that directory, using the filenode naming scheme. The <code class="literal">pg_default</code> tablespace is not accessed through <code class="filename">pg_tblspc</code>, but corresponds to <code class="varname">PGDATA</code><code class="filename">/base</code>. Similarly, the <code class="literal">pg_global</code> tablespace is not accessed through <code class="filename">pg_tblspc</code>, but corresponds to <code class="varname">PGDATA</code><code class="filename">/global</code>. </p><p> The <code class="function">pg_relation_filepath()</code> function shows the entire path (relative to <code class="varname">PGDATA</code>) of any relation. It is often useful as a substitute for remembering many of the above rules. But keep in mind that this function just gives the name of the first segment of the main fork of the relation — you may need to append a segment number and/or <code class="literal">_fsm</code>, <code class="literal">_vm</code>, or <code class="literal">_init</code> to find all the files associated with the relation. </p><p> Temporary files (for operations such as sorting more data than can fit in memory) are created within <code class="varname">PGDATA</code><code class="filename">/base/pgsql_tmp</code>, or within a <code class="filename">pgsql_tmp</code> subdirectory of a tablespace directory if a tablespace other than <code class="literal">pg_default</code> is specified for them. The name of a temporary file has the form <code class="filename">pgsql_tmp<em class="replaceable"><code>PPP</code></em>.<em class="replaceable"><code>NNN</code></em></code>, where <em class="replaceable"><code>PPP</code></em> is the PID of the owning backend and <em class="replaceable"><code>NNN</code></em> distinguishes different temporary files of that backend. </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="storage.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="storage.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="storage-toast.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 68. Database Physical Storage </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 68.2. TOAST</td></tr></table></div></body></html>
