/*
* If relfilenumber is unspecified by the caller then create storage
- * with oid same as relid.
+ * with relfilenumber same as relid if it is a system table otherwise
+ * allocate a new relfilenumber. For more details read comments atop
+ * FirstNormalRelFileNumber declaration.
*/
if (!RelFileNumberIsValid(relfilenumber))
- relfilenumber = relid;
+ {
+ relfilenumber = relid < FirstNormalObjectId ?
+ relid : GetNewRelFileNumber();
Above code says that in the case of system table we want relfilenode to be the same as object id. This technically means that the relfilenode or oid for the system tables would not be exceeding 16383. However in the below lines of code added in the patch, it says there is some chance for the storage path of the user tables from the old cluster conflicting with the storage path of the system tables in the new cluster. Assuming that the OIDs for the user tables on the old cluster would start with 16384 (the first object ID), I see no reason why there would be a conflict.
+/* ----------
+ * RelFileNumber zero is InvalidRelFileNumber.
+ *
+ * For the system tables (OID < FirstNormalObjectId) the initial storage
+ * will be created with the relfilenumber same as their oid. And, later for
+ * any storage the relfilenumber allocated by GetNewRelFileNumber() will start
+ * at 100000. Thus, when upgrading from an older cluster, the relation storage
+ * path for the user table from the old cluster will not conflict with the
+ * relation storage path for the system table from the new cluster. Anyway,
+ * the new cluster must not have any user tables while upgrading, so we needn't
+ * worry about them.
+ * ----------
+ */
+#define FirstNormalRelFileNumber ((RelFileNumber) 100000)
==
When WAL logging the next object id we have the chosen the xlog threshold value as 8192 whereas for relfilenode it is 512. Any reason for choosing this low arbitrary value in case of relfilenumber?
--
With Regards,
Ashutosh Sharma.
