On Wed, Mar 8, 2017 at 6:30 AM, Mark Dilger <hornschnorter@xxxxxxxxx> wrote:
>
>> On Mar 7, 2017, at 12:24 PM, Mark Dilger <hornschnorter@xxxxxxxxx> wrote:
>>
>> Hello,
>>
>> I am attempting to get the tap tests working under windows so as to
>> help review patches for the 10.0 development cycle. I can compile
>> the sources on windows 2008 using the MS Visual C and run the
>>
>> vcregress.bat check
>>
>> without any problems or failures. In an attempt to run the tap tests,
>> I have edited config_default.pl as follows:
>>
>> diff --git a/src/tools/msvc/config_default.pl b/src/tools/msvc/config_default.pl
>> index 97f1af8..1e7b19d 100644
>> --- a/src/tools/msvc/config_default.pl
>> +++ b/src/tools/msvc/config_default.pl
>> @@ -16,7 +16,7 @@ our $config = {
>> extraver => undef, # --with-extra-version=<string>
>> gss => undef, # --with-gssapi=<path>
>> nls => undef, # --enable-nls=<path>
>> - tap_tests => undef, # --enable-tap-tests
>> + tap_tests => 1, # --enable-tap-tests
>> tcl => undef, # --with-tls=<path>
>> perl => undef, # --with-perl
>> python => undef, # --with-python=<path>
>>
>> and when I run
>>
>> vcregress.bat bincheck
>>
>> I get a few failures. Am I doing something wrong, or are these failures
>> the same for other folks? A portion of the log of the regressions follows:
I don't think you are doing anything wrong here.
> I added a bit of debugging logic to PostgresNode.pm, to print out the
> name of the log file being grep'd and the size of that file, and it seems
> in these cases the log file is of size zero (empty).
>
> not ok 10 - SQL CLUSTER run: SQL found in server log c:/jenkins/workspace/unicorns/postgresql/src/bin/scripts/tmp_check/log/010_clusterdb_main.log, length 0
> ok 11 - fails with nonexistent table
> ok 12 - clusterdb -t test1 exit code 0
> not ok 13 - cluster specific table: SQL found in server log c:/jenkins/workspace/unicorns/postgresql/src/bin/scripts/tmp_check/log/010_clusterdb_main.log, length 0
> ok 14 - clusterdb with connection string
> Dubious, test returned 2 (wstat 512, 0x200)
> Failed 2/14 subtests
>
> Perhaps there is a race condition between when the test is run and when the
> log file is flushed? I'm just guessing here....
Just running now the tests by myself to see if I could reproduce your
failures, I have bumped before that into failures for the tests of
pg_ctl and the tests of pg_rewind not responding.. This needs some
serious investigation.
The buildfarm is not running those tests by the way, that's annoying.
--
Michael
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
