Horton

Re: Switch buffile.c/h to use pgoff_t

Chao Li <li.evan.chao@gmail.com>

View thread
From: Chao Li <li.evan.chao@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>, Bryan Green <dbryan.green@gmail.com>
Date: 2025-12-23T02:59:45Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Upgrade BufFile to use int64 for byte positions

  2. Switch buffile.c/h to use pgoff_t instead of off_t

Attachments

On Fri, Dec 19, 2025 at 1:22 PM Michael Paquier <michael@paquier.xyz> wrote:

> On Fri, Dec 19, 2025 at 11:00:54AM +0800, Chao Li wrote:
> > Given MAX_PHYSICAL_FILESIZE is just 1G (2^30), why availbytes has to
> > be pgoff_t instead of just int?
>
> The point of such changes would be to lift this barrier at some point,
> which is what the other thread I am mentioning upthread is also
> pointing at.  It does not change the fact that this code is currently
> not portable as written: off_t can be 4 or 8 bytes depending on the
> environment, and pgoff_t exists to be a stable alternative.  This
> relates as well to the use of long in the tree, all coming down to
> WIN32.
> --
> Michael
>

Sorry, I didn’t explain myself clearly earlier. My main point was to avoid
the awkward mixed-type casts here:
```
if ((pgoff_t) bytestowrite > availbytes)
    bytestowrite = (int) availbytes;
```

I agree that changing availbytes to int would not be a good choice.
Instead, I tried making bytestowrite a pgoff_t, so that the comparison and
assignment can be done without casts, while still keeping the code correct
if MAX_PHYSICAL_FILESIZE is lifted in the future.

I’ve attached a small patch along these lines. It compiles without
warnings, and "make check" passes on my side. What do you think?
Best regards,
==
Chao Li (Evan)
---------------------
HighGo Software Co., Ltd.
https://www.highgo.com/