database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-31 22:04:40 +03:00
Code Activity

Replace explicit PIN entries in pg_depend with an OID range test.

Browse Source 
As of v14, pg_depend contains almost 7000 "pin" entries recording
the OIDs of built-in objects.  This is a fair amount of bloat for
every database, and it adds time to pg_depend lookups as well as
initdb.  We can get rid of all of those entries in favor of an OID
range check, i.e. "OIDs below FirstUnpinnedObjectId are pinned".

(template1 and the public schema are exceptions.  Those exceptions
are now wired into IsPinnedObject() instead of initdb's code for
filling pg_depend, but it's the same amount of cruft either way.)

The contents of pg_shdepend are modified likewise.

Discussion: https://postgr.es/m/3737988.1618451008@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2021-07-15 11:41:47 -04:00
parent e529b2dc37
commit a49d081235
25 changed files with 290 additions and 432 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
doc/src/sgml/bki.sgml
View File

@ -418,19 +418,33 @@
<para>
If <filename>genbki.pl</filename> needs to assign an OID to a catalog
entry that does not have a manually-assigned OID, it will use a value in
the range 10000&mdash;11999. The server's OID counter is set to 12000
at the start of a bootstrap run. Thus objects created by regular SQL
commands during the later phases of bootstrap, such as objects created
while running the <filename>information_schema.sql</filename> script,
receive OIDs of 12000 or above.
the range 10000&mdash;11999. The server's OID counter is set to 10000
at the start of a bootstrap run, so that any objects created on-the-fly
during bootstrap processing also receive OIDs in this range. (The
usual OID assignment mechanism takes care of preventing any conflicts.)
</para>
<para>
Objects with OIDs below <symbol>FirstUnpinnedObjectId</symbol> (12000)
are considered <quote>pinned</quote>, preventing them from being
deleted. (There are a small number of exceptions, which are
hard-wired into <function>IsPinnedObject()</function>.)
<application>initdb</application> forces the OID counter up
to <symbol>FirstUnpinnedObjectId</symbol> as soon as it's ready to
create unpinned objects. Thus objects created during the later phases
of <application>initdb</application>, such as objects created while
running the <filename>information_schema.sql</filename> script, will
not be pinned, while all objects known
to <filename>genbki.pl</filename> will be.
</para>
<para>
OIDs assigned during normal database operation are constrained to be
16384 or higher. This ensures that the range 10000&mdash;16383 is free
for OIDs assigned automatically by <filename>genbki.pl</filename> or
during bootstrap. These automatically-assigned OIDs are not considered
stable, and may change from one installation to another.
during <application>initdb</application>. These
automatically-assigned OIDs are not considered stable, and may change
from one installation to another.
</para>
</sect2>

60
doc/src/sgml/catalogs.sgml
View File

@ -3264,8 +3264,7 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the system catalog the dependent object is in,
or zero for a <symbol>DEPENDENCY_PIN</symbol> entry
The OID of the system catalog the dependent object is in
</para></entry>
</row>
@ -3275,8 +3274,7 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
(references any OID column)
</para>
<para>
The OID of the specific dependent object,
or zero for a <symbol>DEPENDENCY_PIN</symbol> entry
The OID of the specific dependent object
</para></entry>
</row>
@ -3467,19 +3465,6 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><symbol>DEPENDENCY_PIN</symbol> (<literal>p</literal>)</term>
<listitem>
<para>
There is no dependent object; this type of entry is a signal
that the system itself depends on the referenced object, and so
that object must never be deleted. Entries of this type are
created only by <application>initdb</application>. The columns for the
dependent object contain zeroes.
</para>
</listitem>
</varlistentry>
</variablelist>
Other dependency flavors might be needed in future.
@ -3498,6 +3483,19 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
must be satisfied.
</para>
<para>
Most objects created during <application>initdb</application> are
considered <quote>pinned</quote>, which means that the system itself
depends on them. Therefore, they are never allowed to be dropped.
Also, knowing that pinned objects will not be dropped, the dependency
mechanism doesn't bother to make <structname>pg_depend</structname>
entries showing dependencies on them. Thus, for example, a table
column of type <type>numeric</type> notionally has
a <literal>NORMAL</literal> dependency on the <type>numeric</type>
data type, but no such entry actually appears
in <structname>pg_depend</structname>.
</para>
</sect1>
@ -6779,7 +6777,6 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
<para>
The OID of the database the dependent object is in,
or zero for a shared object
or a <symbol>SHARED_DEPENDENCY_PIN</symbol> entry
</para></entry>
</row>
@ -6789,8 +6786,7 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the system catalog the dependent object is in,
or zero for a <symbol>SHARED_DEPENDENCY_PIN</symbol> entry
The OID of the system catalog the dependent object is in
</para></entry>
</row>
@ -6800,8 +6796,7 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
(references any OID column)
</para>
<para>
The OID of the specific dependent object,
or zero for a <symbol>SHARED_DEPENDENCY_PIN</symbol> entry
The OID of the specific dependent object
</para></entry>
</row>
@ -6889,19 +6884,6 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
</listitem>
</varlistentry>
<varlistentry>
<term><symbol>SHARED_DEPENDENCY_PIN</symbol> (<literal>p</literal>)</term>
<listitem>
<para>
There is no dependent object; this type of entry is a signal
that the system itself depends on the referenced object, and so
that object must never be deleted. Entries of this type are
created only by <application>initdb</application>. The columns for the
dependent object contain zeroes.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><symbol>SHARED_DEPENDENCY_TABLESPACE</symbol> (<literal>t</literal>)</term>
<listitem>
@ -6918,6 +6900,14 @@ SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&l
objects.
</para>
<para>
As in the <structname>pg_depend</structname> catalog, most objects
created during <application>initdb</application> are
considered <quote>pinned</quote>. No entries are made
in <structname>pg_shdepend</structname> that would have a pinned
object as either referenced or dependent object.
</para>
</sect1>
<sect1 id="catalog-pg-shdescription">