On 12/8/21 18:10, Thomas Munro wrote:
> On Sun, Dec 5, 2021 at 4:16 AM Andrew Dunstan <and...@dunslane.net> wrote:
>> TAP tests are passed a path to pg_regress as $ENV{PG_REGRESS}. You
>> should be using that. On non-MSVC, the path to a non-installed psql is
>> in this case "$TESTDIR/../../bin/psql" - this should work for VPATH
>> builds as well as non-VPATH. On MSVC it's a bit harder - it's
>> "$top_builddir/$releasetype/psql" but we don't expose that. Perhaps we
>> should. c.f. commit f4ce6c4d3a
> Thanks, that helped. Here's a new version that passes on Windows,
> Unix and Unix with VPATH. I also had to figure out where the DLLs
> are, and make sure that various output files go to the build
> directory, not source directory, if different, which I did by passing
> down another similar environment variable. Better ideas? (It
> confused me for some time that make follows the symlink and runs the
> perl code from inside the source directory.)
The new version appears to set an empty --bindir for pg_regress. Is that
right?
> This adds 2 whole minutes to the recovery check, when running with the
> Windows serial-only scripts on Cirrus CI (using Andres's CI patches).
> For Linux it adds ~20 seconds to the total of -j8 check-world.
> Hopefully that's time well spent, because it adds test coverage for
> all the redo routines, and hopefully soon we won't have to run 'em in
> series on Windows.
>
> Does anyone want to object to the concept of the "pg_user_files"
> directory or the developer-only GUC "allow_relative_tablespaces"?
> There's room for discussion about names; maybe initdb shouldn't create
> the directory unless you ask it to, or something.
I'm slightly worried that some bright spark will discover it and think
it's a good idea for a production setup.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
