Re: making relfilenodes 56 bits
| От | Ashutosh Sharma |
|---|---|
| Тема | Re: making relfilenodes 56 bits |
| Дата | |
| Msg-id | CAE9k0PkS5ObAqo_SqNYaPQ=Bqj=T4Ys=sBvXbsvoa=PO+d-zDg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: making relfilenodes 56 bits (Dilip Kumar <dilipbalaut@gmail.com>) |
| Ответы |
Re: making relfilenodes 56 bits
(Dilip Kumar <dilipbalaut@gmail.com>)
|
| Список | pgsql-hackers |
/*
* 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?
* 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.
On Tue, Jul 26, 2022 at 1:32 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Thu, Jul 21, 2022 at 9:53 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Wed, Jul 20, 2022 at 11:27 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > [v10 patch set]
>
> Hi Dilip, I'm experimenting with these patches and will hopefully have
> more to say soon, but I just wanted to point out that this builds with
> warnings and failed on 3/4 of the CI OSes on cfbot's last run. Maybe
> there is the good kind of uninitialised data on Linux, and the bad
> kind of uninitialised data on those other pesky systems?
Here is the patch to fix the issue, basically, while asserting for the
file existence it was not setting the relfilenumber in the
relfilelocator before generating the path so it was just checking for
the existence of the random path so it was asserting randomly.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления:
Предыдущее
От: David SteeleДата:
Сообщение: Re: Is it correct to say, "invalid data in file \"%s\"", BACKUP_LABEL_FILE in do_pg_backup_stop?