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

On 11/12/2025 10:05 PM, Michael Paquier wrote:
> On Wed, Nov 12, 2025 at 04:58:43PM +0900, Michael Paquier wrote:
>> Thanks.  As the stamps have been pushed for the next minor release, I
>> have applied and backpatched the meson check for now.  I'll look at
>> your patch next, for HEAD.
> > Moving on to the I/O routine changes.  There was a little bit of
> noise in the diffs, like one more comment removed that should still be
> around.  Indentation has needed some adjustment as well, there was one
> funny diff with a cast to pgoff_t.  And done this part as a first
> step, because that's already a nice cut.
> 


Apologies for the state of this and your loss of time.  I was testing a
new workflow and attached the wrong revision.  No excuse, just what
happened.  I will be more careful and do a closer review of diffs going
forward.

> Then, about the test module.
> 
> src/test/modules/Makefile was missing, and once updated I have noticed
> the extra REGRESS in the module's Makefile that made the tests fail
> because we just have a TAP test.  This also meant that TAP_TESTS = 1
> was also missing from the Makefile.  I've fixed these myself as per
> the attached.
> 

I had started down the path of using sql and doing regression testing
and decide instead that a tap test would be better for my specific case
of testing on Windows.

> Anyway, I agree with the point about the restriction with WIN32: there
> can be advantages in being able to run that in other places.  I think
> that we should add a new value for PG_TEST_EXTRA and execute the test
> based on that, or on small machines with little disk space (think
> small SD cards), this is going to blow up.
> 

I was focused on testing the overlapped i/o portion of this for windows
and that is why I went with a tap test.

> Also, is there a point in making that a TAP test?  A SQL test should
> work OK based on the set of SQL functions introduced for the file
> creation step and the validation steps.  We could also use alternate
> outputs if required.
> --
> Michael

Thanks for all the work Michael.  I owe you for the cleanup.  I assume
you are suggesting that we shift from test for windows-specific bugs to
testing for whether any platform that supports N-bit file offsets,
whether PG's I/O layer can actually use them?  Basically we could check
the size of off_t or pgoff_t and the test at those offsets specifically.
 I think we would still want to use sparse files though.

The argument for a TAP test in this case would be File::Temp handles
cleanup automatically for us (even on test failure).  Also, no need for
alternate output files.

I agree we should go to a cross-platform test.  I'm 51/49 in favor of
using TAP tests still, but if you, or others, feel strongly otherwise, I
can restructure it to work that way.

-- 
Bryan Green
EDB: https://www.enterprisedb.com