Re: Type of pg_buffercache_pages()::forknum

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: Type of pg_buffercache_pages()::forknum
Date: 2025-11-18 06:29:57
Message-ID: aRwSZbIsZQYLsxAk@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 12, 2025 at 10:46:12AM +0530, Ashutosh Bapat wrote:
> But C implementation uses ObjectIdGetDatum() where ObjectId is 32 bit integer.
> values[4] = ObjectIdGetDatum(fctx->record[i].forknum);
>
> Since forknum values are within 16 bits and that's unlikely to change
> in future, int2 seems to ok. Also casting it to a wider integer, OID,
> also doesn't seem like a correctness issue. But it does look
> inconsistent and a reader of C implementation may think that the SQL
> datatype used is int4. Should we instead change the C Implementation
> to be
>
> values[4] = Int16GetDatum((int16) fctx->record[i].forknum);
>
> The code has been there for 17 years, and I didn't find any previous
> complaints. I propose to change just the master branch.

This just looks like a copy-pasto to me. Nice catch, will fix on
HEAD.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2025-11-18 06:32:19 Re: nbtree VACUUM's REDO routine doesn't clear page's VACUUM cycle ID
Previous Message Arseniy Mukhin 2025-11-18 06:23:41 Re: Use streaming read I/O in BRIN vacuuming