database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Force pg_upgrade's to preserve pg_class.oid, not pg_class.relfilenode.

Browse Source 
Toast tables have identical pg_class.oid and pg_class.relfilenode, but
for clarity it is good to preserve the pg_class.oid.

Update comments regarding what is preserved, and do some
variable/function renaming for clarity.
This commit is contained in:
Bruce Momjian
2011-01-07 21:25:34 -05:00
parent 541fc3d4df
commit 2896c87ce4
10 changed files with 112 additions and 106 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
contrib/pg_upgrade/pg_upgrade.c
View File

@ -8,23 +8,30 @@
*/
/*
* To simplify the upgrade process, we force certain system items to be
* consistent between old and new clusters:
* To simplify the upgrade process, we force certain system values to be
* identical between old and new clusters:
*
* We control all assignments of pg_class.relfilenode so we can keep the
* same relfilenodes for old and new files. The only exception is
* pg_largeobject, pg_largeobject_metadata, and its indexes, which can
* change due to a cluster, reindex, or vacuum full. (We don't create
* those so have no control over their oid/relfilenode values.)
* We control all assignments of pg_class.oid (and relfilenode) so toast
* oids are the same between old and new clusters. This is important
* because toast oids are stored as toast pointers in user tables.
*
* While pg_class.oid and pg_class.relfilenode are intially the same, they
* can diverge due to cluster, reindex, or vacuum full. The new cluster
* will again have matching pg_class.relfilenode and pg_class.oid values,
* but based on the new relfilenode value, so the old/new oids might
* differ.
* The only place where old/new relfilenode might not match is
* pg_largeobject, pg_largeobject_metadata, and its indexes,
* which can change their relfilenode values due to a cluster, reindex,
* or vacuum full. (We don't create those so have no control over their
* new relfilenode values.)
*
* We control all assignments of pg_type.oid because these are stored
* in composite types.
* FYI, while pg_class.oid and pg_class.relfilenode are intially the same
* in a cluster, but they can diverge due to cluster, reindex, or vacuum
* full. The new cluster will again have matching pg_class.relfilenode
* and pg_class.oid values, but based on the old relfilenode value, so the
* old/new oids might differ.
*
* We control all assignments of pg_type.oid because these oid are stored
* in user composite type values.
*
* We control all assignments of pg_enum.oid because these oid are stored
* in user tables as enum values.
*/