[HACKERS] recovery tests vs windows - Mailing list pgsql-hackers

From Andrew Dunstan
Subject [HACKERS] recovery tests vs windows
Date
Msg-id 8ffbad57-f57f-842e-2671-5e340a808434@2ndQuadrant.com
Whole thread Raw
Responses Re: [HACKERS] recovery tests vs windows  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers
After we got over the Test::More version issue, the recovery tests
proceeded to fail fairly spectacularly in a test run on jacana.


Test 6 fails because there is a CR in the returned stdout from psql. I'm
inclined to adjust that in PostgresNode::safe_psql so we don't have to
do it all over the place.

It looks like at least some tests are failing because of confusion
between Windows paths and the MSys virtualized paths. For example, I see
this:
   2017-04-22 10:01:14.436 EDT [2276] LOG:  archive command failed with   exit code 1   2017-04-22 10:01:14.436 EDT
[2276]DETAIL:  The failed archive   command was: copy "pg_wal\000000010000000000000001"
"/home/pgrunner/bf/root/HEAD/pgsql.build/src/test/recovery/tmp_check/data_master_TCeC/archives\000000010000000000000001"
 The system cannot find the path specified.           0 file(s) copied.
 

Paths that go in recovery.conf or archive commands must of course be
pure Windows paths.In this case the path would have been correct if
prefixed with "c:/Mingw/Msys/1.0"

I'll try to come up with a fix for that.


cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] A note about debugging TAP failures
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] A note about debugging TAP failures