On 08/10/2015 10:32 AM, Andrew Dunstan wrote:
On 08/10/2015 09:55 AM, Tom Lane wrote:
Andrew Dunstan <and...@dunslane.net> writes:
On 08/09/2015 08:58 PM, Michael Paquier wrote:
Sure. Attached is what I have in mind. Contrary to your version we
keep around temp paths should a run succeed after one that has failed
when running make check multiple times in a row. Perhaps it does not
matter much in practice as log files get removed at each new run but I
think that this allows a finer control in case of failure. Feel free
to have a look.
Actually, I don't think this is a very good idea. You could end up with
a whole series of opaquely named directories from a series of failing
runs. If you want to keep the directory after a failure, and want to do
another run, then rename the directory. That's what you have to do with
the main regression tests, too. My version also has the benefit of
changing exactly 3 lines in the source :-)
FWIW, I think we should keep the behavior of the TAP tests as close as
possible to the established behavior of the main regression tests.
It's certainly possible that there's room for improvement in that
benchmark behavior. But let's first converge the test behaviors,
and then have a discussion about whether we want changes, and if
so change all the tests at the same time.
Yeah. To do that we should probably stop using File::Temp to make the
directory, and just use a hardcoded name given to File::Path::mkpath.
If the directory exists, we'd just remove it first.
That won't be a very big change - probably just a handful of lines.
Unfortunately, it's rather more complicated. These tests are extremely
profligate with space and time, creating not less than 29 data
directories in 19 temporary directories, including 14 temp directories
in scripts alone, and not counting those in pg_rewind which puts two
more data directories in a place which is different from all the others.
And of course, in those directories (scripts and pg_ctl) that have
multiple temp directories, we have no idea which one goes with which set
of tests.
It's no wonder that these tests take an inordinate amount of time to run
- on crake, where it takes 23 seconds for "make installcheck" to run, it
takes 176 seconds for "make -C src/bin installcheck" to run. My bet is
all those initdb calls account for a substantial amount of that time.
I think this needs a significant bit of reworking.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
