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 ...
rega
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 bu
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 that's enough to get the "make check"
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 buildfarm client script?
>
> Hu
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? It's just a question of "m
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 passing in the buildfarm,
> then +1.
O
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.
regards, to
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
>> const
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 li
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 wrote:
>> It looks like at least part of the answer is that the
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 that the buildfarm isn't
> running this test. AFAICS, it ru
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
> >> "make check" in src/test/module
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 test. AFAICS, it runs "make installcheck" not
"make check" in s
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" in src/test/modules. I don't kno
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 of the
>> critters would have dupl
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" in src/test/modules. I don
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 (pgsql-hackers@postgresql.org)
To make
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 writes:
>> > On Sat, Jan 21, 2017 at 9:09 PM, Tom Lane wrote:
>> >> H
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 Test::More; ok("2017-01-01" != "null",
> "ok");'
> >> Argument "null" isn't n
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 ne (!=) at -e line 1.
>> Argument "2017-01-01"
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 numeric in numeric n
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 format such as "2017-01-20 21:
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 done_testing() was no
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 cases, eg
$ perl -e 'use wa
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
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 the
critters would have dup
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). But I wonder
> if this is so
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 InvalidTransact
28 matches
Mail list logo