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-19T03:00:54Z
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


> On Dec 19, 2025, at 09:43, Michael Paquier <michael@paquier.xyz> wrote:
> 
> Hi all,
> (Added Bryan in CC as he has been looking at this stuff previously.)
> 
> An mentioned on this thread and as a part of the quest to remove more
> of long in the tree, buffile.c and buffile.h still rely on an
> unportable off_t, which is signed 4 bytes on Windows:
> https://www.postgresql.org/message-id/0f238ff4-c442-42f5-adb8-01b762c94ca1@gmail.com
> 
> Please find attached a patch to do the switch.  I was surprised to see
> that the amount of code to adapt was limited, the routines of
> buffile.h changed in this commit being used in other places that keep
> track of offsets.  Hence these other files just need to do a off_t =>
> pgoff_t flip in a couple of structures to be updated, as far as I can
> see.
> 
> This removes a couple of extra long casts, as well as one comment in
> BufFileSeek() that relates to overflows for large offsets, that would
> not exist with this switch, which is nice.
> 
> Thanks,
> --
> Michael
> <0001-Switch-buffile.c-h-to-use-portable-pgoff_t.patch>


```
 	while (wpos < file->nbytes)
 	{
-		off_t		availbytes;
+		pgoff_t		availbytes;
 		instr_time	io_start;
 		instr_time	io_time;
 
@@ -524,7 +524,7 @@ BufFileDumpBuffer(BufFile *file)
 		bytestowrite = file->nbytes - wpos;
 		availbytes = MAX_PHYSICAL_FILESIZE - file->curOffset;
 
-		if ((off_t) bytestowrite > availbytes)
+		if ((pgoff_t) bytestowrite > availbytes)
 			bytestowrite = (int) availbytes;
```

bytestowrite is of type int, loosing it to pgoff_t then compare with availbytes, if bytestowrite > availbytes, then availbytes must be within the range of int, so the next assignment “bytestowrite = (int) availbytes” is safe, but makes reading difficult.

Given MAX_PHYSICAL_FILESIZE is just 1G (2^30), why availbytes has to be pgoff_t instead of just int?

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/