Re: making relfilenodes 56 bits

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: making relfilenodes 56 bits
Date: 2022-09-23 04:23:48
Message-ID: CAFiTN-tyu24-A1YEotmuthO9A8_3nTEuBKoTv0h9KW9UzcjqAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 21, 2022 at 3:39 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:

> Yeah you are right we can make it uint64. With respect to this, we
> can not directly use uint64 because that is declared in c.h and that
> can not be used in
> postgres_ext.h IIUC. So what are the other option maybe we can
> typedef the RelFIleNumber similar to what c.h done for uint64 i.e.
>
> #ifdef HAVE_LONG_INT_64
> typedef unsigned long int uint64;
> #elif defined(HAVE_LONG_LONG_INT_64)
> typedef long long int int64;
> #endif
>
> I am not liking duplicating this logic but is there any better
> alternative for doing this? Can we move the existing definitions from
> c.h file to some common file (common for client and server)?

Here is the updated patch which fixes all the agreed comments. Except
this one which needs more thoughts, for now I have used unsigned long
int.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Attachment Content-Type Size
v18-0002-Don-t-need-tabespace-id-to-uniquely-identify-rel.patch text/x-patch 11.4 KB
v18-0001-Widen-relfilenumber-from-32-bits-to-56-bits.patch text/x-patch 99.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2022-09-23 04:27:48 Re: making relfilenodes 56 bits
Previous Message Ashutosh Sharma 2022-09-23 03:58:10 Re: binary version of pg_current_wal_insert_lsn and pg_walfile_name functions