database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

Create a "relation mapping" infrastructure to support changing the relfilenodes

Browse Source 
of shared or nailed system catalogs.  This has two key benefits:

* The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs.

* We no longer have to use an unsafe reindex-in-place approach for reindexing
  shared catalogs.

CLUSTER on nailed catalogs now works too, although I left it disabled on
shared catalogs because the resulting pg_index.indisclustered update would
only be visible in one database.

Since reindexing shared system catalogs is now fully transactional and
crash-safe, the former special cases in REINDEX behavior have been removed;
shared catalogs are treated the same as non-shared.

This commit does not do anything about the recently-discussed problem of
deadlocks between VACUUM FULL/CLUSTER on a system catalog and other
concurrent queries; will address that in a separate patch.  As a stopgap,
parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid
such failures during the regression tests.
This commit is contained in:
Tom Lane
2010-02-07 20:48:13 +00:00
parent 7fc30c488f
commit b9b8831ad6
54 changed files with 2316 additions and 585 deletions
Download Patch File Download Diff File Expand all files Collapse all files

64
doc/src/sgml/func.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.500 2010/02/01 15:38:21 rhaas Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.501 2010/02/07 20:48:09 tgl Exp $ -->
<chapter id="functions">
<title>Functions and Operators</title>
@ -13434,6 +13434,68 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
appropriate.
</para>
<para>
The functions shown in <xref linkend="functions-admin-dblocation"> assist
in identifying the specific disk files associated with database objects.
</para>
<indexterm>
<primary>pg_relation_filenode</primary>
</indexterm>
<indexterm>
<primary>pg_relation_filepath</primary>
</indexterm>
<table id="functions-admin-dblocation">
<title>Database Object Location Functions</title>
<tgroup cols="3">
<thead>
<row><entry>Name</entry> <entry>Return Type</entry> <entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<literal><function>pg_relation_filenode</function>(<parameter>relation</parameter> <type>regclass</type>)</literal>
</entry>
<entry><type>oid</type></entry>
<entry>
Filenode number of the relation with the specified OID or name
</entry>
</row>
<row>
<entry>
<literal><function>pg_relation_filepath</function>(<parameter>relation</parameter> <type>regclass</type>)</literal>
</entry>
<entry><type>text</type></entry>
<entry>
File path name of the relation with the specified OID or name
</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
<function>pg_relation_filenode</> accepts the OID or name of a table,
index, sequence, or toast table, and returns the <quote>filenode</> number
currently assigned to it. The filenode is the base component of the file
name(s) used for the relation (see <xref linkend="storage-file-layout">
for more information). For most tables the result is the same as
<structname>pg_class</>.<structfield>relfilenode</>, but for certain
system catalogs <structfield>relfilenode</> is zero and this function must
be used to get the correct value. The function returns NULL if passed
a relation that does not have storage, such as a view.
</para>
<para>
<function>pg_relation_filepath</> is similar to
<function>pg_relation_filenode</>, but it returns the entire file pathname
(relative to the database cluster's data directory <varname>PGDATA</>) of
the relation.
</para>
<para>
The functions shown in <xref
linkend="functions-admin-genfile"> provide native access to