Re: [Patch] Windows relation extension failure at 2GB and 4GB

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