On Mon, Jul 25, 2022 at 9:51 PM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
>
> Hi,
>
> As oid and relfilenumber are linked with each other, I still see that if the oid value reaches the threshold limit,
weare unable to create a table with storage. For example I set FirstNormalObjectId to 4294967294 (one value less than
therange limit of 2^32 -1 = 4294967295). Now when I try to create a table, the CREATE TABLE command gets stuck because
itis unable to find the OID for the comp type although it can find a new relfilenumber.
>
First of all if the OID value reaches to max oid then it should wrap
around to the FirstNormalObjectId and find a new non conflicting OID.
Since in your case the first normaloid is 4294967294 and max oid is
42949672945 there is no scope of wraparound because in this case you
can create at most one object and once you created that then there is
no more unused oid left and with the current patch we are not at all
trying do anything about this.
Now come to the problem we are trying to solve with 56bits
relfilenode. Here we are not trying to extend the limit of the system
to create more than 4294967294 objects. What we are trying to solve
is to not to reuse the same disk filenames for different objects. And
also notice that the relfilenodes can get consumed really faster than
oid so chances of wraparound is more, I mean you can truncate/rewrite
the same relation multiple times so that relation will have the same
oid but will consume multiple relfilenodes.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
