Re: [HACKERS] Failure in commit_ts tap tests

2017-01-27 Thread Tom Lane
Alvaro Herrera 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 ...

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-27 Thread Alvaro Herrera
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

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-27 Thread Andrew Dunstan
On 01/26/2017 03:50 PM, Alvaro Herrera wrote: > Tom Lane wrote: >> Andrew Dunstan 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

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-26 Thread Alvaro Herrera
Tom Lane wrote: > Alvaro Herrera 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

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-26 Thread Tom Lane
Alvaro Herrera 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?

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-26 Thread Alvaro Herrera
Tom Lane wrote: > Andrew Dunstan 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

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-24 Thread Tom Lane
Andrew Dunstan 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.

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-24 Thread Andrew Dunstan
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 >>

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-24 Thread Alvaro Herrera
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

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-24 Thread Andrew Dunstan
On 01/24/2017 03:18 AM, Andrew Dunstan wrote: > > On 01/23/2017 09:22 AM, Tom Lane wrote: >> Andrew Dunstan writes: >>> On 01/23/2017 09:03 AM, Tom Lane wrote: Andrew Dunstan writes: > On 01/20/2017 01:22 PM, Tom Lane

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-24 Thread Andrew Dunstan
On 01/23/2017 09:22 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 01/23/2017 09:03 AM, Tom Lane wrote: >>> Andrew Dunstan writes: On 01/20/2017 01:22 PM, Tom Lane wrote: > It looks like at least part of the answer is

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-23 Thread Stephen Frost
Tom, Andrew, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Andrew Dunstan 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 >

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-23 Thread Tom Lane
Andrew Dunstan writes: > On 01/23/2017 09:03 AM, Tom Lane wrote: >> Andrew Dunstan 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

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-23 Thread Andrew Dunstan
On 01/23/2017 09:03 AM, Tom Lane wrote: > Andrew Dunstan 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"

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-23 Thread Tom Lane
Andrew Dunstan 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

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-23 Thread Andrew Dunstan
On 01/20/2017 01:22 PM, Tom Lane wrote: > Pavan Deolasee 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"

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-21 Thread Tom Lane
David Bowen 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 -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-21 Thread David Bowen
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 wrote: > > > On Sat, Jan 21, 2017 at 9:39 PM, Tom Lane wrote: > >> Pavan Deolasee

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-21 Thread Pavan Deolasee
On Sat, Jan 21, 2017 at 9:39 PM, Tom Lane wrote: > Pavan Deolasee writes: > > On Sat, Jan 21, 2017 at 9:09 PM, Tom Lane wrote: > >> Hm, but what of the "null" value? Also, I get > >> > >> $ perl -e 'use warnings; use

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-21 Thread Tom Lane
Pavan Deolasee writes: > On Sat, Jan 21, 2017 at 9:09 PM, Tom Lane 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

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-21 Thread Pavan Deolasee
On Sat, Jan 21, 2017 at 9:09 PM, Tom Lane 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

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-21 Thread Tom Lane
Pavan Deolasee 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

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-20 Thread Pavan Deolasee
On Sat, Jan 21, 2017 at 12:45 AM, Tom Lane 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

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-20 Thread Tom Lane
Alvaro Herrera 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

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-20 Thread Alvaro Herrera
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

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-20 Thread Tom Lane
Pavan Deolasee 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

Re: [HACKERS] Failure in commit_ts tap tests

2017-01-20 Thread Tom Lane
Pavan Deolasee 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).

[HACKERS] Failure in commit_ts tap tests

2017-01-20 Thread Pavan Deolasee
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