Re: Switch buffile.c/h to use pgoff_t - Mailing list pgsql-hackers

From Chao Li
Subject Re: Switch buffile.c/h to use pgoff_t
Date
Msg-id CAEoWx2msZLqS7AYhy_qQzw=MJUYcp_5V+mwhRsk8DSXFZDcm+A@mail.gmail.com
Whole thread Raw
In response to Re: Switch buffile.c/h to use pgoff_t  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers

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.
Attachment

pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: let ALTER TABLE DROP COLUMN drop whole-row referenced object
Next
From: "cca5507"
Date:
Subject: Re: Why is_admin_of_role() use ROLERECURSE_MEMBERS rather than ROLERECURSE_PRIVS?