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 ...
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
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
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
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?
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
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.
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
>>
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
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
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
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
>
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
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"
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
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"
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
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
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
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
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
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
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
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
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
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
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).
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
28 matches
Mail list logo