Re: making relfilenodes 56 bits

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(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>, vignesh C <vignesh21(at)gmail(dot)com>
Subject: Re: making relfilenodes 56 bits
Date: 2022-08-01 11:57:01
Message-ID: CAFiTN-trubju5YbWAq-BSpZ90-Z6xCVBQE8BVqXqANOZAF1Znw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 29, 2022 at 8:02 PM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
>
>
> + ereport(ERROR,
> + (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> + errmsg("relfilenode" INT64_FORMAT " is too large to be represented as an OID",
> + fctx->record[i].relfilenumber),
> + errhint("Upgrade the extension using ALTER EXTENSION pg_buffercache UPDATE")));
>
> I think it would be good to recommend users to upgrade to the latest version instead of just saying upgrade the pg_buffercache using ALTER EXTENSION ....

This error would be hit if the relfilenumber is out of OID range that
means the user is using a new cluster but old pg_buffercache
extension. So this errhint is about suggesting to upgrade the
extension.

> ==
>
> --- a/contrib/pg_walinspect/sql/pg_walinspect.sql
> +++ b/contrib/pg_walinspect/sql/pg_walinspect.sql
> @@ -39,10 +39,10 @@ SELECT COUNT(*) >= 0 AS ok FROM pg_get_wal_stats_till_end_of_wal(:'wal_lsn1');
> -- Test for filtering out WAL records of a particular table
> -- ===================================================================
>
> -SELECT oid AS sample_tbl_oid FROM pg_class WHERE relname = 'sample_tbl' \gset
> +SELECT relfilenode AS sample_tbl_relfilenode FROM pg_class WHERE relname = 'sample_tbl' \gset
>
> Is this change required? The original query is just trying to fetch table oid not relfilenode and AFAIK we haven't changed anything in table oid.

If you notice the complete test, then you will realize that
sample_tbl_oid are used for verifying that in
pg_get_wal_records_info(), so earlier it was okay if we were using oid
instead of relfilenode because this test case is just creating table
doing some DML and verifying oid in WAL so that will be same as
relfilenode, but that is no longer true. So we will have to check the
relfilenode that was the actual intention of the test.

>
> + * Generate a new relfilenumber. We cannot reuse the old relfilenumber
> + * because of the possibility that that relation will be moved back to the
>
> that that relation -> that relation
>

I think this is a grammatically correct sentence .

I have fixed other comments, and also fixed comments from Alvaro to
use %lld instead of INT64_FORMAT inside the ereport and wherever he
suggested.

I haven't yet changed MAX_RELFILENUMBER to represent the hex
characters because then we will have to change the filename as well.
So I think there is no conclusion on this yet whether we want to keep
it as it is or in hex. And there is another suggestion to change one
of the existing elog to an ereport, so for that I will share a
separate patch.

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

Attachment Content-Type Size
v15-0002-Widen-relfilenumber-from-32-bits-to-56-bits.patch text/x-patch 103.1 KB
v15-0001-Preliminary-refactoring-for-supporting-larger-re.patch text/x-patch 21.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message torikoshia 2022-08-01 12:05:45 Re: Should fix a comment referring to stats collector?
Previous Message Aleksander Alekseev 2022-08-01 11:25:32 Re: [PATCH] Compression dictionaries for JSONB