Thread: [HACKERS] Failure in commit_ts tap tests
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
PostgreSQL Development, 24x7 Support, Training & Services
Attachment
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
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
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
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
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
PostgreSQL Development, 24x7 Support, Training & Services
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
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
PostgreSQL Development, 24x7 Support, Training & Services
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
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 ...
Thanks,
Pavan
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
PostgreSQL Development, 24x7 Support, Training & Services
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 equalThese 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"}'EqualThese 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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