Re: [Patch] Windows relation extension failure at 2GB and 4GB - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [Patch] Windows relation extension failure at 2GB and 4GB
Date
Msg-id aRUxYvrd5cvwJV41@paquier.xyz
Whole thread Raw
In response to Re: [Patch] Windows relation extension failure at 2GB and 4GB  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Thu, Nov 13, 2025 at 12:26:03AM +1300, Thomas Munro wrote:
> On Wed, Nov 12, 2025 at 11:55 PM Dagfinn Ilmari Mannsåker
> <ilmari@ilmari.org> wrote:
>> I just noticed that the check is for 2GB, but the error message says
>> 1GB.
>
> -Dsegsize only accepts integers here and it's expressed in GB, so only
> 1 will actually work.  Presumably you could set a size up to 2GB - 1
> block using -Dsegsize_blocks instead and it would work, but that's
> clearly documented as developer-only.  I noticed that too and
> scratched my head for a moment, but I think Michael used a defensible
> cut-off and a defensible error message, they just disagree :-)

Yep, I was also scratching my head a bit on this one for the meson
bit, dived into its history before sticking to this message last
weekend for consistency.

In summary, the current formula is the same as d3b111e3205b, with a
wording much older than that: 3c6248a828af.  The original option in
this commit was only settable with GB in mind as units for the segment
size, hence a 4-byte off_t could work only with 1GB back originally,
hence the error message worded this way.  I doubt that it's worth
caring much for fancier segment sizes, but if we do we'd better change
that for meson and configure.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [PATCH] Add hints for invalid binary encoding names in encode/decode functions
Next
From: Masahiko Sawada
Date:
Subject: Re: Add mode column to pg_stat_progress_vacuum