Re: Peter Eisentraut 2014-11-03 5457f54e.4020...@gmx.net
On 11/2/14 2:00 PM, Noah Misch wrote:
Ick; I concur with your judgment on those aspects of the IPC::Cmd design.
Thanks for investigating. So, surviving options include:
1. Require IPC::Run.
2. Write our own run() that reports the
On Mon, Nov 3, 2014 at 4:44 PM, Peter Eisentraut pete...@gmx.net wrote:
On 10/29/14 8:42 AM, Robert Haas wrote:
I'm sympathetic to that line of reasoning, but I really think that if
you want to keep this infrastructure, it needs to be made portable.
Let me clarify that this was my intention.
On 11/2/14 2:00 PM, Noah Misch wrote:
Ick; I concur with your judgment on those aspects of the IPC::Cmd design.
Thanks for investigating. So, surviving options include:
1. Require IPC::Run.
2. Write our own run() that reports the raw exit code.
3. Distill the raw exit code from the
Peter Eisentraut pete...@gmx.net writes:
I thank you for this research, but I suggest that we ship 9.4 as is,
that is with requiring IPC::Run and --enable-* option. All the possible
alternatives will clearly need more rounds of portability testing. We
can then evaluate these changes for 9.5
On 10/29/14 8:42 AM, Robert Haas wrote:
I'm sympathetic to that line of reasoning, but I really think that if
you want to keep this infrastructure, it needs to be made portable.
Let me clarify that this was my intention. I have looked at many test
frameworks, many of which are much nicer than
On Mon, Nov 03, 2014 at 04:40:39PM -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I thank you for this research, but I suggest that we ship 9.4 as is,
that is with requiring IPC::Run and --enable-* option. All the possible
alternatives will clearly need more rounds of
On Thu, Oct 30, 2014 at 01:57:15AM -0400, Noah Misch wrote:
On Wed, Oct 29, 2014 at 08:14:07PM -0400, Peter Eisentraut wrote:
On 10/28/14 9:09 PM, Peter Eisentraut wrote:
I have looked into IPC::Cmd, but the documentation keeps telling me that
to do anything interesting I have to have
Noah Misch n...@leadboat.com writes:
On Thu, Oct 30, 2014 at 10:49:33PM -0400, Tom Lane wrote:
I think the installs as such aren't the only reason for the sucky
performance. We need to also reduce the number of initdb cycles incurred
by the TAP tests. It's useless for example that the
On 10/30/2014 09:17 PM, Andres Freund wrote:
On 2014-10-30 21:03:43 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-10-30 20:13:53 -0400, Tom Lane wrote:
As I said upthread, that approach seems to me to be contrary to the
project policy about how configure should
Noah Misch n...@leadboat.com writes:
Ick; I concur with your judgment on those aspects of the IPC::Cmd design.
Thanks for investigating. So, surviving options include:
1. Require IPC::Run.
2. Write our own run() that reports the raw exit code.
3. Distill the raw exit code from the
On 2014-10-30 01:57:15 -0400, Noah Misch wrote:
On Wed, Oct 29, 2014 at 08:14:07PM -0400, Peter Eisentraut wrote:
On 10/28/14 9:09 PM, Peter Eisentraut wrote:
I have looked into IPC::Cmd, but the documentation keeps telling me that
to do anything interesting I have to have IPC::Run
I wrote:
Yup, you read that right, it took 32 seconds to run those dozen utterly
trivial tests. As far as I could tell by eyeball, pretty much all of the
time went into test 11, which is odd since it seems not significantly
different from the others. I think there's something wacky about
I wrote:
Yup, you read that right, it took 32 seconds to run those dozen utterly
trivial tests. As far as I could tell by eyeball, pretty much all of the
time went into test 11, which is odd since it seems not significantly
different from the others. I think there's something wacky about
On 10/30/2014 05:23 PM, Tom Lane wrote:
I wrote:
Yup, you read that right, it took 32 seconds to run those dozen utterly
trivial tests. As far as I could tell by eyeball, pretty much all of the
time went into test 11, which is odd since it seems not significantly
different from the others. I
Andrew Dunstan and...@dunslane.net writes:
On 10/30/2014 05:23 PM, Tom Lane wrote:
Anyway, I can confirm Peter's statement that the current tests work even
on quite old platforms, as long as you install IPC::Run.
So, I'm a bit confused. Is the --enable-tap-tests config setting still
on the
On 10/30/14, 4:55 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 10/30/2014 05:23 PM, Tom Lane wrote:
Anyway, I can confirm Peter's statement that the current tests work even
on quite old platforms, as long as you install IPC::Run.
So, I'm a bit confused. Is the
Jim Nasby jim.na...@bluetreble.com writes:
On 10/30/14, 4:55 PM, Tom Lane wrote:
I think it should be. You should not have to have either prove or
IPC::Run (or, IIRC, even Perl) in order to do make check-world.
Could configure detect if we have IPC::Run? ISTM it'd be nice to make this
On 10/30/14, 5:32 PM, Tom Lane wrote:
Jim Nasby jim.na...@bluetreble.com writes:
On 10/30/14, 4:55 PM, Tom Lane wrote:
I think it should be. You should not have to have either prove or
IPC::Run (or, IIRC, even Perl) in order to do make check-world.
Could configure detect if we have
Jim Nasby jim.na...@bluetreble.com writes:
If our policy is that tests are there primarily for developers then I agree
with you.
If not, then would we be OK with make check being a no-op unless you'd
configured with --enable-make-check?
Making this something you have to enable will
On 2014-10-30 19:30:04 -0400, Tom Lane wrote:
Jim Nasby jim.na...@bluetreble.com writes:
If our policy is that tests are there primarily for developers then I agree
with you.
If not, then would we be OK with make check being a no-op unless you'd
configured with --enable-make-check?
Andres Freund and...@2ndquadrant.com writes:
On 2014-10-30 19:30:04 -0400, Tom Lane wrote:
At some point down the road that value judgement might (hopefully will)
reverse, and then we could deal with it by making --enable-tap-tests the
default. But even then there would be a place for
On 2014-10-30 19:53:54 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-10-30 19:30:04 -0400, Tom Lane wrote:
At some point down the road that value judgement might (hopefully will)
reverse, and then we could deal with it by making --enable-tap-tests the
Andres Freund and...@2ndquadrant.com writes:
On 2014-10-30 19:53:54 -0400, Tom Lane wrote:
Well, for example, you don't have and don't want to install IPC::Run.
Well, that's what the hypothetical configure test is for. I see little
reason in this specific case to do anything more complicated
On Thu, Oct 30, 2014 at 04:54:25PM +0100, Andres Freund wrote:
On 2014-10-30 01:57:15 -0400, Noah Misch wrote:
On Wed, Oct 29, 2014 at 08:14:07PM -0400, Peter Eisentraut wrote:
On 10/28/14 9:09 PM, Peter Eisentraut wrote:
I have looked into IPC::Cmd, but the documentation keeps telling
On 2014-10-30 20:13:53 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-10-30 19:53:54 -0400, Tom Lane wrote:
Well, for example, you don't have and don't want to install IPC::Run.
Well, that's what the hypothetical configure test is for. I see little
reason in
Andres Freund and...@2ndquadrant.com writes:
On 2014-10-30 20:13:53 -0400, Tom Lane wrote:
As I said upthread, that approach seems to me to be contrary to the
project policy about how configure should behave.
I don't think that holds much water. There's a fair amount of things
that configure
On 2014-10-30 21:24:04 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-10-30 21:03:43 -0400, Tom Lane wrote:
Meh. Right now, it's easy to dismiss these tests as unimportant,
figuring that they play little part in whether the completed build
is reliable. But
On 10/30/2014 09:37 PM, Andres Freund wrote:
On 2014-10-30 21:24:04 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-10-30 21:03:43 -0400, Tom Lane wrote:
Meh. Right now, it's easy to dismiss these tests as unimportant,
figuring that they play little part in
Andrew Dunstan and...@dunslane.net writes:
There are other issues. I am not going to enable this in the buildfarm
until the check test can work from a single install. It's insane for the
bin tests to take an order of magnitude longer than the main regression
suite.
I think the installs as
Peter Eisentraut pete...@gmx.net writes:
On 10/7/14 1:57 PM, Tom Lane wrote:
Peter had a patch to eliminate the overhead of multiple subinstalls;
not sure where that stands, but presumably it would address your issue.
It will need some cleverness to sort out the parallel make issues that
I wrote:
I took a quick look. I concur with Fabien that the dependency on
MAKELEVEL seems pretty horrid: in particular, will that not break the
ability to initiate make check from somewhere below the top directory?
Another use-case that seems to be broken both by Peter's patch and my
proposed
On Thu, Oct 30, 2014 at 10:49:33PM -0400, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
There are other issues. I am not going to enable this in the buildfarm
until the check test can work from a single install. It's insane for the
bin tests to take an order of magnitude
On Tue, Oct 28, 2014 at 9:01 PM, Peter Eisentraut pete...@gmx.net wrote:
Well, they caught the fact that pg_basebackup can't back up tablespaces
with names longer than 99 characters, for example.
But it's wrong to expect the primary value of tests to be to detect
previously unknown bugs.
On 10/28/14 9:09 PM, Peter Eisentraut wrote:
I agree we should get rid of subplans.
I removed subtests. Everything now runs (without skipping) with Perl
5.8+ plus IPC::Run.
I have looked into IPC::Cmd, but the documentation keeps telling me that
to do anything interesting I have to have
On Wed, Oct 29, 2014 at 08:14:07PM -0400, Peter Eisentraut wrote:
On 10/28/14 9:09 PM, Peter Eisentraut wrote:
I have looked into IPC::Cmd, but the documentation keeps telling me that
to do anything interesting I have to have IPC::Run anyway. I'll give it
a try, though.
I tried this,
On 10/7/14 1:57 PM, Tom Lane wrote:
Peter had a patch to eliminate the overhead of multiple subinstalls;
not sure where that stands, but presumably it would address your issue.
It will need some cleverness to sort out the parallel make issues that
were brought up in the review thread.
--
On 10/27/14 11:41 AM, Robert Haas wrote:
Beyond all that, I have serious doubts about whether, even if we
eventually get these tests mostly working in most places, whether they
will actually catch any bugs.
Well, they caught the fact that pg_basebackup can't back up tablespaces
with names
On 10/28/14 12:46 AM, Noah Misch wrote:
Agreed. Having this framework when the pg_upgrade test suite originated would
have prevented acquiring parallel implementations in Perl and shell.
Yes, that was certainly a motivation, and I would like to continue work
on pg_upgrade testing.
On Sun, Oct 26, 2014 at 12:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The larger issue though is that even with both the above things fixed,
the TAP tests would still be an expensive no-op on the majority of
buildfarm members. AFAICT, I do not own a single machine on which the
current TAP
On 10/27/2014 05:41 PM, Robert Haas wrote:
On Sun, Oct 26, 2014 at 12:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The larger issue though is that even with both the above things fixed,
the TAP tests would still be an expensive no-op on the majority of
buildfarm members. AFAICT, I do not own a
On 10/27/2014 11:41 AM, Robert Haas wrote:
On Sun, Oct 26, 2014 at 12:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The larger issue though is that even with both the above things fixed,
the TAP tests would still be an expensive no-op on the majority of
buildfarm members. AFAICT, I do not own a
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 10/27/2014 05:41 PM, Robert Haas wrote:
Beyond all that, I have serious doubts about whether, even if we
eventually get these tests mostly working in most places, whether they
will actually catch any bugs.
The existing tests are not very
Andrew Dunstan and...@dunslane.net writes:
Yeah. I think at the very least they should be removed from the
check-world and installcheck-world targets until this is sorted out.
+1 for doing that in the 9.4 branch; I'm surprised we've not already
heard bitching from packagers about how far we've
On Mon, Oct 27, 2014 at 12:31:56PM -0400, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 10/27/2014 05:41 PM, Robert Haas wrote:
Beyond all that, I have serious doubts about whether, even if we
eventually get these tests mostly working in most places, whether they
On 10/9/14 3:38 PM, Robert Haas wrote:
The problem is that running initdb --not-a-valid-option leaves $? set
to 256, as seems entirely unsurprising. After running the anonymous
block passed to it, Test::Builder::subtest calls Test::Build::finalize
which calls Test::Build::_ending, which sets
On 10/07/2014 01:57 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I don't much like the idea of doing an install/initdb/start for every
directory in src/bin, though. Can't we at least manage a single
installation directory for all these?
Peter had a patch to eliminate the
Andrew Dunstan and...@dunslane.net writes:
On 10/07/2014 01:57 PM, Tom Lane wrote:
Peter had a patch to eliminate the overhead of multiple subinstalls;
not sure where that stands, but presumably it would address your issue.
Is there any progress on this. I'm reluctant to add this to the
On 10/26/2014 12:29 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 10/07/2014 01:57 PM, Tom Lane wrote:
Peter had a patch to eliminate the overhead of multiple subinstalls;
not sure where that stands, but presumably it would address your issue.
Is there any progress on
Andrew Dunstan and...@dunslane.net writes:
On 10/26/2014 12:29 PM, Tom Lane wrote:
The pathname length problem I noted in
http://www.postgresql.org/message-id/16477.1413831...@sss.pgh.pa.us
seems like a show-stopper as well, since undoubtedly a number of
buildfarm critters are using
On 10/07/2014 12:15 AM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 6, 2014 at 8:15 PM, Peter Eisentraut pete...@gmx.net wrote:
The TAP tests
are arguably already much easier to debug than pg_regress ever was.
Well, maybe. I wasn't able, after about 5 minutes of
On 10/07/2014 09:53 AM, Andrew Dunstan wrote:
On 10/07/2014 12:15 AM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 6, 2014 at 8:15 PM, Peter Eisentraut pete...@gmx.net
wrote:
The TAP tests
are arguably already much easier to debug than pg_regress ever was.
Well,
Andrew Dunstan and...@dunslane.net writes:
I don't much like the idea of doing an install/initdb/start for every
directory in src/bin, though. Can't we at least manage a single
installation directory for all these?
Peter had a patch to eliminate the overhead of multiple subinstalls;
not sure
On Thu, 2014-10-02 at 21:18 -0400, Robert Haas wrote:
If none of this gets us closer to an answer, I can try to produce a
patch that produces more details for such failures.
A test that fails for no reason that can be gleaned from the output is
not an improvement over not having a test at
On Mon, Oct 6, 2014 at 8:15 PM, Peter Eisentraut pete...@gmx.net wrote:
On Thu, 2014-10-02 at 21:18 -0400, Robert Haas wrote:
If none of this gets us closer to an answer, I can try to produce a
patch that produces more details for such failures.
A test that fails for no reason that can be
On Thu, Oct 2, 2014 at 10:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
make check-world dies ingloriously for me, like this:
FWIW, it works fine for me on my Mac laptop, using the Perl 5.16.2 that
comes standard with OSX 10.9.5. I did have to install
make check-world dies ingloriously for me, like this:
/bin/sh ../../../config/install-sh -c -d tmp_check/log
make -C ../../..
DESTDIR='/Users/rhaas/pgsql/src/bin/initdb'/tmp_check/install install
'/Users/rhaas/pgsql/src/bin/initdb'/tmp_check/log/install.log 21
cd .
On 10/2/14 3:19 PM, Robert Haas wrote:
1..2
ok 1 - initdb with invalid option nonzero exit code
ok 2 - initdb with invalid option prints error message
# Looks like your test exited with 256 just after 2.
not ok 3 - initdb options handling
# Failed test 'initdb options
On 2014-10-02 17:09:43 -0400, Peter Eisentraut wrote:
On 10/2/14 3:19 PM, Robert Haas wrote:
1..2
ok 1 - initdb with invalid option nonzero exit code
ok 2 - initdb with invalid option prints error message
# Looks like your test exited with 256 just after 2.
not ok 3 -
On Thu, Oct 2, 2014 at 5:09 PM, Peter Eisentraut pete...@gmx.net wrote:
On 10/2/14 3:19 PM, Robert Haas wrote:
1..2
ok 1 - initdb with invalid option nonzero exit code
ok 2 - initdb with invalid option prints error message
# Looks like your test exited with 256 just after 2.
Robert Haas robertmh...@gmail.com writes:
make check-world dies ingloriously for me, like this:
FWIW, it works fine for me on my Mac laptop, using the Perl 5.16.2 that
comes standard with OSX 10.9.5. I did have to install IPC::Run from
CPAN though.
# Failed test 'initdb options handling'
#
I wrote:
Also, noticing that what you're using is evidently Perl 5.12, I'm
wondering whether our TAP test scripts require a fairly new Perl version.
I recall some of my Salesforce colleagues griping that the TAP scripts
didn't work with older Perls.
Well, they definitely don't work with Perl
61 matches
Mail list logo
