Horton

Thread

Commits

  1. Remove test for COMMENT ON DATABASE

  2. tests: Use the right Perl operator

  1. Failure in commit_ts tap tests

    Pavan Deolasee <pavan.deolasee@gmail.com> — 2017-01-20T17:23:24Z

    I see a consistent failure while running "make -C
src/test/modules/commit_ts/ check" on a server compiled with
--enable-tap-tests. This is on the master branch (193a7d791)

t/004_restart.pl ....
1..16
ok 1 - getting ts of InvalidTransactionId reports error
ok 2 - expected error from InvalidTransactionId
ok 3 - getting ts of BootstrapTransactionId succeeds
ok 4 - timestamp of BootstrapTransactionId is null
ok 5 - getting ts of FrozenTransactionId succeeds
ok 6 - timestamp of FrozenTransactionId is null
ok 7 - committs for FirstNormalTransactionId is null
not ok 8 - commit timestamp recorded

Upon investigating logs, I see that perl complains about using != operator
on non-numeric argument.

Argument "" isn't numeric in numeric ne (!=) at t/004_restart.pl line 57.
Argument "Fri Jan 20 07:59:52.322811 2017 PST" isn't numeric in numeric ne
(!=) at t/004_restart.pl line 57.
not ok 8 - commit timestamp recorded

Changing the operator to "ne" works for me (patch attached). But I wonder
if this is something specific to my system? Am I using a wrong/stale
version on OSX Sierra? I'm surprised nobody reported this problem earlier.

$ perl -v

This is perl 5, version 18, subversion 2 (v5.18.2) built for
darwin-thread-multi-2level
(with 2 registered patches, see perl -V for more detail)

Copyright 1987-2013, Larry Wall

Thanks,
Pavan

-- 
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

  2. Re: Failure in commit_ts tap tests

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-01-20T18:10:16Z

    Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> I see a consistent failure while running "make -C
> src/test/modules/commit_ts/ check" on a server compiled with
> --enable-tap-tests. This is on the master branch (193a7d791)
> ...
> Changing the operator to "ne" works for me (patch attached). But I wonder
> if this is something specific to my system? Am I using a wrong/stale
> version on OSX Sierra? I'm surprised nobody reported this problem earlier.

That's just weird.  I agree this patch is correct (and I see Alvaro
just pushed it), but why isn't the code failing elsewhere?  I see
no such warning on my RHEL6 box (perl 5.10.1) nor on my OSX Sierra
laptop (perl 5.18.2, should be same as yours).  Do you have any
nondefault Perl modules installed?

			regards, tom lane

  3. Re: Failure in commit_ts tap tests

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-01-20T18:22:17Z

    Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> I'm surprised nobody reported this problem earlier.

It looks like at least part of the answer is that the buildfarm isn't
running this test.  AFAICS, it runs "make installcheck" not
"make check" in src/test/modules.  I don't know whether any of the
critters would have duplicated the failure, but they weren't trying.

I don't know if any of the other src/test/modules/ subdirectories
test more in make check mode than make installcheck mode, but if
they do, we probably oughta change the buildfarm script.

			regards, tom lane

  4. Re: Failure in commit_ts tap tests

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2017-01-20T18:27:02Z

    Pavan Deolasee wrote:

> Argument "" isn't numeric in numeric ne (!=) at t/004_restart.pl line 57.
> Argument "Fri Jan 20 07:59:52.322811 2017 PST" isn't numeric in numeric ne (!=) at t/004_restart.pl line 57.
> not ok 8 - commit timestamp recorded
> 
> Changing the operator to "ne" works for me (patch attached). But I wonder
> if this is something specific to my system? Am I using a wrong/stale
> version on OSX Sierra? I'm surprised nobody reported this problem earlier.

Hmm.  The test works fine for me, even if it should be obvious that the
use of the != operator is wrong.  I don't understand why it causes a
failure only for you.

> $ perl -v

> This is perl 5, version 18, subversion 2 (v5.18.2) built for
> darwin-thread-multi-2level
> (with 2 registered patches, see perl -V for more detail)

Mine says:

This is perl 5, version 20, subversion 2 (v5.20.2) built for x86_64-linux-gnu-thread-multi
(with 92 registered patches, see perl -V for more detail)

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  5. Re: Failure in commit_ts tap tests

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-01-20T19:15:08Z

    Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Hmm.  The test works fine for me, even if it should be obvious that the
> use of the != operator is wrong.  I don't understand why it causes a
> failure only for you.

Even more interesting, the warning appears as-expected in stripped down
test cases, eg

$ perl -e 'use warnings; use Test::More; ok("Foo" ne "bar", "ok");'
ok 1 - ok
# Tests were run but no plan was declared and done_testing() was not seen.

$ perl -e 'use warnings; use Test::More; ok("Foo" != "bar", "ok");'
Argument "bar" isn't numeric in numeric ne (!=) at -e line 1.
Argument "Foo" isn't numeric in numeric ne (!=) at -e line 1.
not ok 1 - ok
#   Failed test 'ok'
#   at -e line 1.
# Tests were run but no plan was declared and done_testing() was not seen.

I really don't understand why this complains but the same perl version
is happy with (the previous coding in) 004_restart.pl.  Perl bug?

			regards, tom lane

  6. Re: Failure in commit_ts tap tests

    Pavan Deolasee <pavan.deolasee@gmail.com> — 2017-01-21T05:40:48Z

    On Sat, Jan 21, 2017 at 12:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>
> Even more interesting, the warning appears as-expected in stripped down
> test cases, eg
>
> $ perl -e 'use warnings; use Test::More; ok("Foo" ne "bar", "ok");'
> ok 1 - ok
> # Tests were run but no plan was declared and done_testing() was not seen.
>
> $ perl -e 'use warnings; use Test::More; ok("Foo" != "bar", "ok");'
> Argument "bar" isn't numeric in numeric ne (!=) at -e line 1.
> Argument "Foo" isn't numeric in numeric ne (!=) at -e line 1.
> not ok 1 - ok
> #   Failed test 'ok'
> #   at -e line 1.
> # Tests were run but no plan was declared and done_testing() was not seen.
>
> I really don't understand why this complains but the same perl version
> is happy with (the previous coding in) 004_restart.pl.  Perl bug?
>
>
I think I understand why it's only affecting me and not others.
I've PGDATESTYLE set to "Postgres, MDY" in my bashrc and that formats the
commit timestamp as "Fri Jan 20 07:59:52.322811 2017 PST". If I unset that,
the result comes in a format such as  "2017-01-20 21:31:47.766371-08".
Looks like perl doesn't throw an error if it can parse the leading part of
the string as a numeric. It still throws a warning, but the test passes.

Thanks,
Pavan

-- 
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

  7. Re: Failure in commit_ts tap tests

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-01-21T15:39:56Z

    Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> I think I understand why it's only affecting me and not others.
> I've PGDATESTYLE set to "Postgres, MDY" in my bashrc and that formats the
> commit timestamp as "Fri Jan 20 07:59:52.322811 2017 PST". If I unset that,
> the result comes in a format such as  "2017-01-20 21:31:47.766371-08".
> Looks like perl doesn't throw an error if it can parse the leading part of
> the string as a numeric. It still throws a warning, but the test passes.

Hm, but what of the "null" value?  Also, I get

$ perl -e 'use warnings; use Test::More; ok("2017-01-01" != "null", "ok");'
Argument "null" isn't numeric in numeric ne (!=) at -e line 1.
Argument "2017-01-01" isn't numeric in numeric ne (!=) at -e line 1.
ok 1 - ok
# Tests were run but no plan was declared and done_testing() was not seen.

			regards, tom lane

  8. Re: Failure in commit_ts tap tests

    Pavan Deolasee <pavan.deolasee@gmail.com> — 2017-01-21T16:02:43Z

    On Sat, Jan 21, 2017 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

>
>
> Hm, but what of the "null" value?  Also, I get
>
> $ perl -e 'use warnings; use Test::More; ok("2017-01-01" != "null", "ok");'
> Argument "null" isn't numeric in numeric ne (!=) at -e line 1.
> Argument "2017-01-01" isn't numeric in numeric ne (!=) at -e line 1.
> ok 1 - ok
>

It declares the test as "passed", right? I am not saying that's a correct
behaviour, but that's why we didn't catch the problem earlier. May be its a
bug in the Test module?

If I add a non-numeric prefix to LHS string, test fails.

$ perl -e 'use warnings; use Test::More; ok("Fri 2017-46" != "null", "ok");'
Argument "null" isn't numeric in numeric ne (!=) at -e line 1.
Argument "Fri 2017-46" isn't numeric in numeric ne (!=) at -e line 1.
not ok 1 - ok
#   Failed test 'ok'
#   at -e line 1.
# Tests were run but no plan was declared and done_testing() was not seen.

Thanks,
Pavan

-- 
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

  9. Re: Failure in commit_ts tap tests

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-01-21T16:09:14Z

    Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> On Sat, Jan 21, 2017 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hm, but what of the "null" value?  Also, I get
>> 
>> $ perl -e 'use warnings; use Test::More; ok("2017-01-01" != "null", "ok");'
>> Argument "null" isn't numeric in numeric ne (!=) at -e line 1.
>> Argument "2017-01-01" isn't numeric in numeric ne (!=) at -e line 1.
>> ok 1 - ok

> It declares the test as "passed", right?

Oh!  So it does.  That is one darn weird behavior of the != operator.

> I am not saying that's a correct
> behaviour, but that's why we didn't catch the problem earlier.

Check.  Mystery solved.

There's still the point that we're not actually exercising this script
in the buildfarm ...

			regards, tom lane

  10. Re: Failure in commit_ts tap tests

    Pavan Deolasee <pavan.deolasee@gmail.com> — 2017-01-21T16:38:48Z

    On Sat, Jan 21, 2017 at 9:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> > On Sat, Jan 21, 2017 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Hm, but what of the "null" value?  Also, I get
> >>
> >> $ perl -e 'use warnings; use Test::More; ok("2017-01-01" != "null",
> "ok");'
> >> Argument "null" isn't numeric in numeric ne (!=) at -e line 1.
> >> Argument "2017-01-01" isn't numeric in numeric ne (!=) at -e line 1.
> >> ok 1 - ok
>
> > It declares the test as "passed", right?
>
> Oh!  So it does.  That is one darn weird behavior of the != operator.
>
>
Indeed! See this:

# first numeric matches, doesn't check beyond that
$ perl -e 'if ("2017-23" != "2017-24") {print "Not equal\n"} else {print
"Equal\n"}'
Equal

# first numeric doesn't match, operators works ok
$ perl -e 'if ("2017-23" != "2018-24") {print "Not equal\n"} else {print
"Equal\n"}'
Not equal

# comparison of numeric with non-numeric, works ok
$ perl -e 'if ("2017-23" != "Foo") {print "Not equal\n"} else {print
"Equal\n"}'
Not equal

# numeric on RHS, works ok
$ perl -e 'if ("Foo" != "2018-24") {print "Not equal\n"} else {print
"Equal\n"}'
Not equal

These tests show that the operator returns the correct result it finds a
numeric value at the start of the string, either on LHS or RHS. Also, it
will only compare the numeric values until first non-numeric character is
found.

# no numeric on either side
$ perl -e 'if ("Fri 2017-23" != "Fri 2017-23") {print "Not equal\n"} else
{print "Equal\n"}'
Equal

*# no numeric on either side, arbitrary strings declared as equal*
$ perl -e 'if ("Fri 2017-23" != "Foo") {print "Not equal\n"} else {print
"Equal\n"}'
Equal

These two tests show why we saw no failure earlier. If neither LHS or RHS
string has a starting numeric value, the operator declares the arguments as
equal, irrespective of their values. I tested the same with == operator and
that also exhibits the same behaviour. Weird and I wonder how it's not a
source of constant bugs in perl code (I don't use perl a lot, so may be
those who do are used to either turning warnings on or know this already.


>
>
> There's still the point that we're not actually exercising this script
> in the buildfarm ...
>

Yes indeed.

Thanks,
Pavan

-- 
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

  11. Re: Failure in commit_ts tap tests

    David Bowen <dmb0317@gmail.com> — 2017-01-21T20:03:21Z

    If the intent of the test is to compare strings, you should be using ne not
!=.

David Bowen

On Sat, Jan 21, 2017 at 10:38 AM, Pavan Deolasee <pavan.deolasee@gmail.com>
wrote:

>
>
> On Sat, Jan 21, 2017 at 9:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> Pavan Deolasee <pavan.deolasee@gmail.com> writes:
>> > On Sat, Jan 21, 2017 at 9:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> >> Hm, but what of the "null" value?  Also, I get
>> >>
>> >> $ perl -e 'use warnings; use Test::More; ok("2017-01-01" != "null",
>> "ok");'
>> >> Argument "null" isn't numeric in numeric ne (!=) at -e line 1.
>> >> Argument "2017-01-01" isn't numeric in numeric ne (!=) at -e line 1.
>> >> ok 1 - ok
>>
>> > It declares the test as "passed", right?
>>
>> Oh!  So it does.  That is one darn weird behavior of the != operator.
>>
>>
> Indeed! See this:
>
> # first numeric matches, doesn't check beyond that
> $ perl -e 'if ("2017-23" != "2017-24") {print "Not equal\n"} else {print
> "Equal\n"}'
> Equal
>
> # first numeric doesn't match, operators works ok
> $ perl -e 'if ("2017-23" != "2018-24") {print "Not equal\n"} else {print
> "Equal\n"}'
> Not equal
>
> # comparison of numeric with non-numeric, works ok
> $ perl -e 'if ("2017-23" != "Foo") {print "Not equal\n"} else {print
> "Equal\n"}'
> Not equal
>
> # numeric on RHS, works ok
> $ perl -e 'if ("Foo" != "2018-24") {print "Not equal\n"} else {print
> "Equal\n"}'
> Not equal
>
> These tests show that the operator returns the correct result it finds a
> numeric value at the start of the string, either on LHS or RHS. Also, it
> will only compare the numeric values until first non-numeric character is
> found.
>
> # no numeric on either side
> $ perl -e 'if ("Fri 2017-23" != "Fri 2017-23") {print "Not equal\n"} else
> {print "Equal\n"}'
> Equal
>
> *# no numeric on either side, arbitrary strings declared as equal*
> $ perl -e 'if ("Fri 2017-23" != "Foo") {print "Not equal\n"} else {print
> "Equal\n"}'
> Equal
>
> These two tests show why we saw no failure earlier. If neither LHS or RHS
> string has a starting numeric value, the operator declares the arguments as
> equal, irrespective of their values. I tested the same with == operator and
> that also exhibits the same behaviour. Weird and I wonder how it's not a
> source of constant bugs in perl code (I don't use perl a lot, so may be
> those who do are used to either turning warnings on or know this already.
>
>
>>
>>
>> There's still the point that we're not actually exercising this script
>> in the buildfarm ...
>>
>
> Yes indeed.
>
> Thanks,
> Pavan
>
> --
>  Pavan Deolasee                   http://www.2ndQuadrant.com/
>  PostgreSQL Development, 24x7 Support, Training & Services
>

  12. Re: Failure in commit_ts tap tests

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-01-21T20:35:21Z

    David Bowen <dmb0317@gmail.com> writes:
> If the intent of the test is to compare strings, you should be using ne not
> !=.

Sure.  We were just confused as to how it had ever appeared to work.

			regards, tom lane

  13. Re: Failure in commit_ts tap tests

    Andrew Dunstan <andrew.dunstan@2ndquadrant.com> — 2017-01-23T13:28:37Z

    
On 01/20/2017 01:22 PM, Tom Lane wrote:
> Pavan Deolasee <pavan.deolasee@gmail.com> writes:
>> I'm surprised nobody reported this problem earlier.
> It looks like at least part of the answer is that the buildfarm isn't
> running this test.  AFAICS, it runs "make installcheck" not
> "make check" in src/test/modules.  I don't know whether any of the
> critters would have duplicated the failure, but they weren't trying.
>
> I don't know if any of the other src/test/modules/ subdirectories
> test more in make check mode than make installcheck mode, but if
> they do, we probably oughta change the buildfarm script.
>
> 			


Is there a reason why these tests aren't run under installcheck? If
there is a justification I can look at it, or we should decide on one
canonical mode of running the tests and stick to that.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  14. Re: Failure in commit_ts tap tests

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-01-23T14:03:14Z

    Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 01/20/2017 01:22 PM, Tom Lane wrote:
>> It looks like at least part of the answer is that the buildfarm isn't
>> running this test.  AFAICS, it runs "make installcheck" not
>> "make check" in src/test/modules.  I don't know whether any of the
>> critters would have duplicated the failure, but they weren't trying.

> Is there a reason why these tests aren't run under installcheck? If
> there is a justification I can look at it, or we should decide on one
> canonical mode of running the tests and stick to that.

Well, for at least some of them, "make check" is necessary because they
need to change postmaster parameters or load special shared libraries.

			regards, tom lane

  15. Re: Failure in commit_ts tap tests

    Andrew Dunstan <andrew.dunstan@2ndquadrant.com> — 2017-01-23T14:20:28Z

    
On 01/23/2017 09:03 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On 01/20/2017 01:22 PM, Tom Lane wrote:
>>> It looks like at least part of the answer is that the buildfarm isn't
>>> running this test.  AFAICS, it runs "make installcheck" not
>>> "make check" in src/test/modules.  I don't know whether any of the
>>> critters would have duplicated the failure, but they weren't trying.
>> Is there a reason why these tests aren't run under installcheck? If
>> there is a justification I can look at it, or we should decide on one
>> canonical mode of running the tests and stick to that.
> Well, for at least some of them, "make check" is necessary because they
> need to change postmaster parameters or load special shared libraries.
>
> 			

OK, so should we just change "make installcheck" to "make check"?

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  16. Re: Failure in commit_ts tap tests

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-01-23T14:22:28Z

    Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 01/23/2017 09:03 AM, Tom Lane wrote:
>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>> On 01/20/2017 01:22 PM, Tom Lane wrote:
>>>> It looks like at least part of the answer is that the buildfarm isn't
>>>> running this test.  AFAICS, it runs "make installcheck" not
>>>> "make check" in src/test/modules.

> OK, so should we just change "make installcheck" to "make check"?

I'm in favor (just for src/test/modules, to be clear).

			regards, tom lane

  17. Re: Failure in commit_ts tap tests

    Stephen Frost <sfrost@snowman.net> — 2017-01-23T14:23:39Z

    Tom, Andrew,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> > On 01/20/2017 01:22 PM, Tom Lane wrote:
> >> It looks like at least part of the answer is that the buildfarm isn't
> >> running this test.  AFAICS, it runs "make installcheck" not
> >> "make check" in src/test/modules.  I don't know whether any of the
> >> critters would have duplicated the failure, but they weren't trying.
> 
> > Is there a reason why these tests aren't run under installcheck? If
> > there is a justification I can look at it, or we should decide on one
> > canonical mode of running the tests and stick to that.
> 
> Well, for at least some of them, "make check" is necessary because they
> need to change postmaster parameters or load special shared libraries.

Yes, having to fight with the buildfarm to have something like pgaudit
properly tested by the build animals is extremely frustrating.

The TAP tests do seem to allow that sort of thing these days, though I
haven't peronsally tried to create any which load special shared
libraries yet.  I also haven't looked to see how many animals actually
run them, though hopefully we can encourage more people to do so as we
improve our testing with them.

Thanks!

Stephen

  18. Re: Failure in commit_ts tap tests

    Andrew Dunstan <andrew.dunstan@2ndquadrant.com> — 2017-01-24T08:18:24Z

    
On 01/23/2017 09:22 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On 01/23/2017 09:03 AM, Tom Lane wrote:
>>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>>> On 01/20/2017 01:22 PM, Tom Lane wrote:
>>>>> It looks like at least part of the answer is that the buildfarm isn't
>>>>> running this test.  AFAICS, it runs "make installcheck" not
>>>>> "make check" in src/test/modules.
>> OK, so should we just change "make installcheck" to "make check"?
> I'm in favor (just for src/test/modules, to be clear).
>
> 			



Yes. There will be some consequent buildfarm code cleanup, but this will
test shortly on crake.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  19. Re: Failure in commit_ts tap tests

    Andrew Dunstan <andrew.dunstan@2ndquadrant.com> — 2017-01-24T10:06:34Z

    
On 01/24/2017 03:18 AM, Andrew Dunstan wrote:
>
> On 01/23/2017 09:22 AM, Tom Lane wrote:
>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>> On 01/23/2017 09:03 AM, Tom Lane wrote:
>>>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>>>> On 01/20/2017 01:22 PM, Tom Lane wrote:
>>>>>> It looks like at least part of the answer is that the buildfarm isn't
>>>>>> running this test.  AFAICS, it runs "make installcheck" not
>>>>>> "make check" in src/test/modules.
>>> OK, so should we just change "make installcheck" to "make check"?
>> I'm in favor (just for src/test/modules, to be clear).
>>
>> 			
>
>
> Yes. There will be some consequent buildfarm code cleanup, but this will
> test shortly on crake.
>

Well, that crashed. The DDL deparse comment test should not assume that
contrib_regression exists. Possibly it should create it if it doesn't
exist. The buildfarm mostly runs with USE_DB_MODULE=1 so we don't
constantly overwrite the same db.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  20. Re: Failure in commit_ts tap tests

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2017-01-24T10:17:12Z

    Andrew Dunstan wrote:

> Well, that crashed. The DDL deparse comment test should not assume that
> contrib_regression exists. Possibly it should create it if it doesn't
> exist. The buildfarm mostly runs with USE_DB_MODULE=1 so we don't
> constantly overwrite the same db.

Maybe we can drop that line and put it back once we get COMMENT ON
CURRENT_DATABASE.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  21. Re: Failure in commit_ts tap tests

    Andrew Dunstan <andrew.dunstan@2ndquadrant.com> — 2017-01-24T11:36:36Z

    
On 01/24/2017 05:17 AM, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
>> Well, that crashed. The DDL deparse comment test should not assume that
>> contrib_regression exists. Possibly it should create it if it doesn't
>> exist. The buildfarm mostly runs with USE_DB_MODULE=1 so we don't
>> constantly overwrite the same db.
> Maybe we can drop that line and put it back once we get COMMENT ON
> CURRENT_DATABASE.
>

Works for me.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  22. Re: Failure in commit_ts tap tests

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-01-24T13:12:07Z

    Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 01/24/2017 05:17 AM, Alvaro Herrera wrote:
>> Maybe we can drop that line and put it back once we get COMMENT ON
>> CURRENT_DATABASE.

> Works for me.

If that's enough to get the "make check" cases passing in the buildfarm,
then +1.

			regards, tom lane

  23. Re: Failure in commit_ts tap tests

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2017-01-26T20:50:52Z

    Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> > On 01/24/2017 05:17 AM, Alvaro Herrera wrote:
> >> Maybe we can drop that line and put it back once we get COMMENT ON
> >> CURRENT_DATABASE.
> 
> > Works for me.
> 
> If that's enough to get the "make check" cases passing in the buildfarm,
> then +1.

Okay, done.

It is really quite annoying that the buildfarm doesn't do what stock
tests do.  What about pushing a bit stronger for having these
optimizations as part of the standard build run, instead of being only
in the buildfarm client script?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  24. Re: Failure in commit_ts tap tests

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-01-26T21:16:50Z

    Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> It is really quite annoying that the buildfarm doesn't do what stock
> tests do.  What about pushing a bit stronger for having these
> optimizations as part of the standard build run, instead of being only
> in the buildfarm client script?

Huh?  It's just a question of "make check" vs "make installcheck".
They each have their uses.

			regards, tom lane

  25. Re: Failure in commit_ts tap tests

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2017-01-26T21:46:39Z

    Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > It is really quite annoying that the buildfarm doesn't do what stock
> > tests do.  What about pushing a bit stronger for having these
> > optimizations as part of the standard build run, instead of being only
> > in the buildfarm client script?
> 
> Huh?  It's just a question of "make check" vs "make installcheck".
> They each have their uses.

The current problem is because the buildfarm uses a different database.
See https://postgr.es/m/e6084b89-07a7-7e57-51ee-d7b8fc9ec864@2ndQuadrant.com
(When I wrote the para quoted above, I thought this was for performance,
but now I realize it's not so.  Anyway the point stands that buildfarm
does things differently.)

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  26. Re: Failure in commit_ts tap tests

    Andrew Dunstan <andrew.dunstan@2ndquadrant.com> — 2017-01-27T08:35:37Z

    
On 01/26/2017 03:50 PM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>> On 01/24/2017 05:17 AM, Alvaro Herrera wrote:
>>>> Maybe we can drop that line and put it back once we get COMMENT ON
>>>> CURRENT_DATABASE.
>>> Works for me.
>> If that's enough to get the "make check" cases passing in the buildfarm,
>> then +1.
> Okay, done.
>
> It is really quite annoying that the buildfarm doesn't do what stock
> tests do.  What about pushing a bit stronger for having these
> optimizations as part of the standard build run, instead of being only
> in the buildfarm client script?
>


There is nothing that the buildfarm does that's not a stock test. What
it does is run the stock tests with USE_MODULE_DB=1 (which you can do
too). That is something provided for in our Make files. The reason is
that otherwise we constantly overwrite the regression database. That can
make it a lot harder to go back after a buildfarm run and find errors.

That's why you should not assume the name of the database when you're
writing a test.

cheers

andrew
-- 

Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  27. Re: Failure in commit_ts tap tests

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2017-01-27T12:22:06Z

    Andrew Dunstan wrote:

> On 01/26/2017 03:50 PM, Alvaro Herrera wrote:

> > It is really quite annoying that the buildfarm doesn't do what stock
> > tests do.  What about pushing a bit stronger for having these
> > optimizations as part of the standard build run, instead of being only
> > in the buildfarm client script?
> 
> There is nothing that the buildfarm does that's not a stock test. What
> it does is run the stock tests with USE_MODULE_DB=1 (which you can do
> too). That is something provided for in our Make files. The reason is
> that otherwise we constantly overwrite the regression database. That can
> make it a lot harder to go back after a buildfarm run and find errors.

There is a lot that you *can* do using the stock makefiles, but that
"make check-world" doesn't do.  Why aren't we using USE_MODULE_DB=1 in
"make check-world", is my question.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  28. Re: Failure in commit_ts tap tests

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-01-27T12:56:19Z

    Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> There is a lot that you *can* do using the stock makefiles, but that
> "make check-world" doesn't do.  Why aren't we using USE_MODULE_DB=1 in
> "make check-world", is my question.

Well, that option isn't all that convenient for manual use ...

			regards, tom lane