Re: bin checks taking too long.

Lists: pgsql-hackers
From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: bin checks taking too long.
Date: 2014-12-23 00:56:07
Message-ID: 5498BDA7.3090708@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Currently the buildfarm animal crake (my development instance) is
running the bin check, but not any other animal. These tests still take
for too long, not least because each set of tests requires a separate
install.

I have complained about this before, but we don't seem to have made any
progress. I am very reluctant to put this check into a buildfarm client
release until that is addressed. Is there really nothing we can do about
it? This is getting more important since we now have another feature
that we want to get into a buildfarm client release.

cheers

andrew


From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bin checks taking too long.
Date: 2014-12-23 03:41:26
Message-ID: 5498E466.9040808@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 12/22/14 7:56 PM, Andrew Dunstan wrote:
> Currently the buildfarm animal crake (my development instance) is
> running the bin check, but not any other animal. These tests still take
> for too long, not least because each set of tests requires a separate
> install.

You can avoid that by using make installcheck.

> Is there really nothing we can do about it?

There is, but it's not straightforward, as it turns out. Ideas are welcome.

Also, as you can imagine, any build system changes are bottlenecked on
Windows support.


From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bin checks taking too long.
Date: 2014-12-23 16:11:42
Message-ID: 5499943E.9010204@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 12/22/2014 10:41 PM, Peter Eisentraut wrote:
> On 12/22/14 7:56 PM, Andrew Dunstan wrote:
>> Currently the buildfarm animal crake (my development instance) is
>> running the bin check, but not any other animal. These tests still take
>> for too long, not least because each set of tests requires a separate
>> install.
> You can avoid that by using make installcheck.

Not working too well:

make -C pg_ctl installcheck
make[1]: Entering directory
`/home/bf/bfr/root/HEAD/pgsql.build/src/bin/pg_ctl'
cd /home/bf/bfr/root/HEAD/pgsql.build/../pgsql/src/bin/pg_ctl &&
TESTDIR='/home/bf/bfr/root/HEAD/pgsql.build/src/bin/pg_ctl'
PATH="/home/bf/bfr/root/HEAD/inst/bin:$PATH" PGPORT='65648' prove -I
/home/bf/bfr/root/HEAD/pgsql.build/../pgsql/src/test/perl/ --verbose
t/*.pl
Use of uninitialized value $ENV{"top_builddir"} in concatenation (.)
or string at t/001_start_stop.pl line 17.
file not found: /src/test/regress/pg_regress at
/home/bf/bfr/root/HEAD/pgsql.build/../pgsql/src/test/perl/TestLib.pm
line 142.

This was invoked like this:

cd $pgsql/src/bin && make NO_LOCALE=1 installcheck

Note that it's a vpath build.

cheers

andrew


From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bin checks taking too long.
Date: 2014-12-23 18:55:46
Message-ID: 5499BAB2.50306@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 12/23/2014 11:11 AM, Andrew Dunstan wrote:
>
> On 12/22/2014 10:41 PM, Peter Eisentraut wrote:
>> On 12/22/14 7:56 PM, Andrew Dunstan wrote:
>>> Currently the buildfarm animal crake (my development instance) is
>>> running the bin check, but not any other animal. These tests still take
>>> for too long, not least because each set of tests requires a separate
>>> install.
>> You can avoid that by using make installcheck.
>
>
> Not working too well:
>
> make -C pg_ctl installcheck
> make[1]: Entering directory
> `/home/bf/bfr/root/HEAD/pgsql.build/src/bin/pg_ctl'
> cd /home/bf/bfr/root/HEAD/pgsql.build/../pgsql/src/bin/pg_ctl &&
> TESTDIR='/home/bf/bfr/root/HEAD/pgsql.build/src/bin/pg_ctl'
> PATH="/home/bf/bfr/root/HEAD/inst/bin:$PATH" PGPORT='65648' prove -I
> /home/bf/bfr/root/HEAD/pgsql.build/../pgsql/src/test/perl/ --verbose
> t/*.pl
> Use of uninitialized value $ENV{"top_builddir"} in concatenation (.)
> or string at t/001_start_stop.pl line 17.
> file not found: /src/test/regress/pg_regress at
> /home/bf/bfr/root/HEAD/pgsql.build/../pgsql/src/test/perl/TestLib.pm
> line 142.
>
> This was invoked like this:
>
> cd $pgsql/src/bin && make NO_LOCALE=1 installcheck
>
> Note that it's a vpath build.
>
>

The attached patch seems to fix this. However, running installcheck also
makes very little difference to the time. These checks still take around
100 seconds on my machine, including around 60 for the script tests.
That seems ridiculously long, when the whole core regression suite takes
23 seconds.

cheers

andrew

Attachment Content-Type Size
bincheckfix.patch text/x-patch 574 bytes

From: Noah Misch <noah(at)leadboat(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bin checks taking too long.
Date: 2014-12-24 07:56:31
Message-ID: 20141224075631.GA1924346@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, Dec 23, 2014 at 01:55:46PM -0500, Andrew Dunstan wrote:
> On 12/23/2014 11:11 AM, Andrew Dunstan wrote:
> > Use of uninitialized value $ENV{"top_builddir"} in concatenation (.)
> > or string at t/001_start_stop.pl line 17.
> > file not found: /src/test/regress/pg_regress at
> >/home/bf/bfr/root/HEAD/pgsql.build/../pgsql/src/test/perl/TestLib.pm
> > line 142.
> >
> >This was invoked like this:
> >
> > cd $pgsql/src/bin && make NO_LOCALE=1 installcheck
> >
> >Note that it's a vpath build.
> >
> >
>
> The attached patch seems to fix this.

Oops. Your fix looks good.

> However, running installcheck also
> makes very little difference to the time. These checks still take around 100
> seconds on my machine, including around 60 for the script tests. That seems
> ridiculously long, when the whole core regression suite takes 23 seconds.

I am satisfied with the performance of the TAP suites.