|
15 | 15 | * oids are the same between old and new clusters. This is important
|
16 | 16 | * because toast oids are stored as toast pointers in user tables.
|
17 | 17 | *
|
18 |
| - * The only place where old/new relfilenode might not match is |
19 |
| - * pg_largeobject, pg_largeobject_metadata, and its indexes, |
20 |
| - * which can change their relfilenode values due to a cluster, reindex, |
21 |
| - * or vacuum full. (We don't create those so have no control over their |
22 |
| - * new relfilenode values.) |
23 |
| - * |
24 | 18 | * FYI, while pg_class.oid and pg_class.relfilenode are intially the same
|
25 |
| - * in a cluster, but they can diverge due to cluster, reindex, or vacuum |
26 |
| - * full. The new cluster will again have matching pg_class.relfilenode |
27 |
| - * and pg_class.oid values, but based on the old relfilenode value, so the |
28 |
| - * old/new oids might differ. |
| 19 | + * in a cluster, but they can diverge due to CLUSTER, REINDEX, or VACUUM |
| 20 | + * FULL. The new cluster will have matching pg_class.oid and |
| 21 | + * pg_class.relfilenode values and be based on the old oid value. This can |
| 22 | + * cause the old and new pg_class.relfilenode values to differ. |
29 | 23 | *
|
30 |
| - * We control all assignments of pg_type.oid because these oid are stored |
| 24 | + * We control all assignments of pg_type.oid because these oids are stored |
31 | 25 | * in user composite type values.
|
32 | 26 | *
|
33 |
| - * We control all assignments of pg_enum.oid because these oid are stored |
| 27 | + * We control all assignments of pg_enum.oid because these oids are stored |
34 | 28 | * in user tables as enum values.
|
35 | 29 | */
|
36 | 30 |
|
|
0 commit comments