Horton

Thread

Commits

  1. Combine initdb tests that successfully create a data directory.

  1. Drongo vs. 9.4 initdb TAP test

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-12-23T00:24:09Z

    Buildfarm member drongo has been failing the initdb TAP test in the
9.4 branch for the last week or two:

# Running: rm -rf 'C:\prog\bf\root\REL9_4_STABLE\pgsql.build\src\bin\initdb\tmp_check\tmp_testAHN7'/*
'rm' is not recognized as an internal or external command,
operable program or batch file.
Bail out!  system rm -rf 'C:\prog\bf\root\REL9_4_STABLE\pgsql.build\src\bin\initdb\tmp_check\tmp_testAHN7'/* failed: 256

The test has not changed; rather, it looks like drongo wasn't
trying to run it before.

This test is passing in the newer branches --- evidently due to
the 9.5-era commit 1a629c1b1, which removed this TAP script's
dependency on "rm -rf".  So we should either back-patch that
commit into 9.4 or undo whatever configuration change caused
drongo to try to run more tests.  I favor the former.

			regards, tom lane

  2. Re: Drongo vs. 9.4 initdb TAP test

    Michael Paquier <michael@paquier.xyz> — 2019-12-23T00:53:41Z

    On Sun, Dec 22, 2019 at 07:24:09PM -0500, Tom Lane wrote:
> This test is passing in the newer branches --- evidently due to
> the 9.5-era commit 1a629c1b1, which removed this TAP script's
> dependency on "rm -rf".  So we should either back-patch that
> commit into 9.4 or undo whatever configuration change caused
> drongo to try to run more tests.  I favor the former.

I would prefer simply removing the dependency of rm -rf in the tests,
even if that's for a short time as 9.4 is EOL in two months.  A
back-patch applies without conflicts, and the tests are able to pass.
Would you prefer doing it yourself?  I have not checked yet on
Windows, better to make sure that it does not fail.
--
Michael

  3. Re: Drongo vs. 9.4 initdb TAP test

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-12-23T00:57:34Z

    Michael Paquier <michael@paquier.xyz> writes:
> On Sun, Dec 22, 2019 at 07:24:09PM -0500, Tom Lane wrote:
>> This test is passing in the newer branches --- evidently due to
>> the 9.5-era commit 1a629c1b1, which removed this TAP script's
>> dependency on "rm -rf".  So we should either back-patch that
>> commit into 9.4 or undo whatever configuration change caused
>> drongo to try to run more tests.  I favor the former.

> I would prefer simply removing the dependency of rm -rf in the tests,
> even if that's for a short time as 9.4 is EOL in two months.

I'd vote for back-patching 1a629c1b1 as-is, or is that what you meant?

> A back-patch applies without conflicts, and the tests are able to pass.
> Would you prefer doing it yourself?  I have not checked yet on
> Windows, better to make sure that it does not fail.

I don't have the ability to test it on Windows --- if you want to do that,
feel free to do so and push.

			regards, tom lane

  4. Re: Drongo vs. 9.4 initdb TAP test

    Michael Paquier <michael@paquier.xyz> — 2019-12-23T01:53:10Z

    On Sun, Dec 22, 2019 at 07:57:34PM -0500, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> On Sun, Dec 22, 2019 at 07:24:09PM -0500, Tom Lane wrote:
>>> This test is passing in the newer branches --- evidently due to
>>> the 9.5-era commit 1a629c1b1, which removed this TAP script's
>>> dependency on "rm -rf".  So we should either back-patch that
>>> commit into 9.4 or undo whatever configuration change caused
>>> drongo to try to run more tests.  I favor the former.
> 
>> I would prefer simply removing the dependency of rm -rf in the tests,
>> even if that's for a short time as 9.4 is EOL in two months.
> 
> I'd vote for back-patching 1a629c1b1 as-is, or is that what you meant?

Yes, that's what I meant.

>> A back-patch applies without conflicts, and the tests are able to pass.
>> Would you prefer doing it yourself?  I have not checked yet on
>> Windows, better to make sure that it does not fail.
> 
> I don't have the ability to test it on Windows --- if you want to do that,
> feel free to do so and push.

Thanks, done.  The original commit had a typo in one comment, fixed by
a9793e07 later on so I have included this fix as well here.
--
Michael