On Mon, Jul 25, 2022 at 9:51 PM Ashutosh Sharma <ashu.coe...@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, we are unable to create a table with > storage. For example I set FirstNormalObjectId to 4294967294 (one value less > than the range limit of 2^32 -1 = 4294967295). Now when I try to create a > table, the CREATE TABLE command gets stuck because it is 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
