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()
On Mon, Nov 3, 2014 at 4:44 PM, Peter Eisentraut 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. I have l
On Mon, Nov 03, 2014 at 04:40:39PM -0500, Tom Lane wrote:
> Peter Eisentraut 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 t
On 11/03/2014 04:44 PM, Peter Eisentraut 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. I have looked at many te
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
Peter Eisentraut 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 in peace.
I
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 t
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
On 10/30/2014 09:17 PM, Andres Freund wrote:
On 2014-10-30 21:03:43 -0400, Tom Lane wrote:
Andres Freund 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
Noah Misch 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 pg_controldata te
On Thu, Oct 30, 2014 at 10:49:33PM -0400, Tom Lane wrote:
> Andrew Dunstan 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 m
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
prop
Peter Eisentraut 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
> were brought
Andrew Dunstan 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 such aren't the
On 10/30/2014 09:37 PM, Andres Freund wrote:
On 2014-10-30 21:24:04 -0400, Tom Lane wrote:
Andres Freund 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
On 2014-10-30 21:24:04 -0400, Tom Lane wrote:
> Andres Freund 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 that may not
Andres Freund 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 that may not always be true. If they do become
>> a significant par
On 2014-10-30 21:03:43 -0400, Tom Lane wrote:
> Andres Freund 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'
Andres Freund 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 detects automat
On 2014-10-30 20:13:53 -0400, Tom Lane wrote:
> Andres Freund 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 specif
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
Andres Freund 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 than check
> for p
On 2014-10-30 19:53:54 -0400, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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
>> --disable-tap-tests.
On 2014-10-30 19:30:04 -0400, Tom Lane wrote:
> Jim Nasby 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 thi
Jim Nasby 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 seriously limit the number
On 10/30/14, 5:32 PM, Tom Lane wrote:
Jim Nasby 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 m
Jim Nasby 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
> automatic instead of r
On 10/30/14, 4:55 PM, Tom Lane wrote:
Andrew Dunstan 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 set
Andrew Dunstan 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 table?
I thi
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
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 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::Ru
Noah Misch 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 IPC::Cmd::run() error
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
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 IP
On Tue, Oct 28, 2014 at 9:01 PM, Peter Eisentraut 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. Yes, that has
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.
> Concrete
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 lo
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.
--
Se
On Mon, Oct 27, 2014 at 12:31:56PM -0400, Tom Lane wrote:
> Heikki Linnakangas 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
Andrew Dunstan 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 moved the goalpos
Heikki Linnakangas 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 useful, but it c
On 10/27/2014 11:41 AM, Robert Haas wrote:
On Sun, Oct 26, 2014 at 12:29 PM, Tom Lane 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 wh
On 10/27/2014 05:41 PM, Robert Haas wrote:
On Sun, Oct 26, 2014 at 12:29 PM, Tom Lane 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 whi
On Sun, Oct 26, 2014 at 12:29 PM, Tom Lane 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 tests will consent
Andrew Dunstan 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 buildroots with path
On 10/26/2014 12:29 PM, Tom Lane wrote:
Andrew Dunstan 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
Andrew Dunstan 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
> buildfarm client
On 10/07/2014 01:57 PM, Tom Lane wrote:
Andrew Dunstan 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 su
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 se
On Mon, Oct 6, 2014 at 8:15 PM, Peter Eisentraut 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 gleane
Andrew Dunstan 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 where that stand
On 10/07/2014 09:53 AM, Andrew Dunstan wrote:
On 10/07/2014 12:15 AM, Tom Lane wrote:
Robert Haas writes:
On Mon, Oct 6, 2014 at 8:15 PM, Peter Eisentraut
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 mi
On 10/07/2014 12:15 AM, Tom Lane wrote:
Robert Haas writes:
On Mon, Oct 6, 2014 at 8:15 PM, Peter Eisentraut 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 searching, to
locate either a log file
Robert Haas writes:
> On Mon, Oct 6, 2014 at 8:15 PM, Peter Eisentraut 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 searching, to
> locate either a log file with details of the failure or th
On Mon, Oct 6, 2014 at 8:15 PM, Peter Eisentraut 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 gleane
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 te
On Thu, Oct 2, 2014 at 10:08 PM, Tom Lane wrote:
> Robert Haas 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.
>
>> #
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 Pe
Robert Haas 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'
> # at /opt/local/li
On Thu, Oct 2, 2014 at 5:09 PM, 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 o
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
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 optio
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 2>&1
cd . && TESTDIR='/Users/rhaas/pgsq
66 matches
Mail list logo
