| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Bryan Green <dbryan(dot)green(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [Patch] Windows relation extension failure at 2GB and 4GB |
| Date: | 2025-11-13 01:16:18 |
| Message-ID: | aRUxYvrd5cvwJV41@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)ilmari(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2025-11-13 02:10:45 | Re: Add mode column to pg_stat_progress_vacuum |
| Previous Message | Fujii Masao | 2025-11-13 00:58:46 | Re: [PATCH] Add hints for invalid binary encoding names in encode/decode functions |