On Thu, Nov 06, 2025 at 11:17:52AM -0600, Bryan Green wrote:
> On 11/5/2025 11:05 PM, Michael Paquier wrote:
>> It seems to me that a couple of extra code paths should be handled in
>> the first patch, and I have spotted three of them. None of them are
>> critical as they are related to WAL segments, just become masked and
>> inconsistent:
>> - xlogrecovery.c, pg_pread() called with a cast to off_t. WAL
>> segments have a max size of 1GB, meaning that we're OK.
>> - xlogreader.c, pg_pread() with a cast to off_t.
>> - walreceiver.c, pg_pwrite().
>>
>> Except for these three spots, the first patch looks like a cut good
>> enough on its own.
>
> Latest patch attached that includes these code paths.
That feels OK for me. Thomas, do you have a different view on the
matter for HEAD? Like long, I would just switch to something that we
have in the tree that's fixed.
And +1 for the idea to restrict the segment size to never be more than
2GB based on a ./configure and meson check on the back branches. In
PG15 and older branches, we already enforced a check by the way. See
src/tools/msvc/Solution.pm which was the only way to compile the code
with visual studio so one would have never seen the limitations except
if they had the idea to edit the perl scripts (FWIW, I've done exactly
that in the past for a past project at $company, never touched the
segsize):
# only allow segsize 1 for now, as we can't do large files yet in windows
die "Bad segsize $options->{segsize}"
unless $options->{segsize} == 1;
So this is a meson issue that goes down to v16, when using a VS
compiler. Was there a different compiler where off_t is also 4 bytes?
MinGW is mentioned as clear by Thomas.
--
Michael
