[check_postgres] failure of make test in

[Kevin Brannen]

> From: Christoph Berg [mailto:christoph.berg at credativ.de]
>
> > $ diff -u t/02_dbstats.t t/02_dbstats.t.new
> >
> > +$ENV{PGDATABASE} = undef;  # prevent user's default DB from
> > +influencing the test
>
> Hi,
>
> thanks for debugging that, good catch!
>
> I'd rather not change all individual t/* files to include that line, so instead I put an "env -i" into the suggested testsuite call in README.md and README.dev.

Do whatever you think best, but I'm not sure you need to do that everywhere.
This the only test that had issues with this var.

Oh, doing "env -i make test" is the wrong thing to do for those who have a custom Pg install (like we do). Wiping out the env-vars means I lose very needed things like: PGPORT, PGUSER, PGPATH, PGDIR, PGDATA, and any other vars that Pg actually needs to find itself and work because Pg is not installed in the system dirs. Oops! :)

> Re: Kevin Brannen 2017-07-07 <CE782658D4A193498ABF0FD938CD77BE26BE8754 at EFJDFWMB01.EFJDFW.local>
> > Christoph,
> >
> > My apologies for not including a patch for the other file. I didn't even think about fixing it until after I sent you the other email. Here's what works on my server:
> >
> > diff --git a/t/01_validate_range.t b/t/01_validate_range.t index
> > -    is $w, 1.15292150460685e+18, 'Should have warning == 1 exobytes';
> > -    is $c, 4.84227031934876e+19, 'Should have critical == 42 exobytes';
> > +    is $w, 0+1024**6, 'Should have warning == 1 exobytes';
> > +    is $c, 42*1024**6, 'Should have critical == 42 exobytes';
>
> I'm not sure what's happening there - the tests pass just fine on 32 bit Debian/sid for me.

Yes, I suspected it was a 32-v-64 bit thing. Along with extra precision comes extra responsibility, or Spiderman says something like that. ;-)  Maybe get someone else on the list with a 64 server to test? FWIW, I'm using Perl 5.18.4 (compiled from perl.org source) on Centos 6.7. I really doubt the Centos part will matter, but the Perl version might (but probably not).

>
> >  INTEGER: {
> >
> > For reasons I don't quite understand, I had to do "0+1024**6", without the addition trick then the value goes into scientific notation, which causes the check to fail. With the addition, then it stays as a whole integer. Zettabytes does not need that as it's always too big and so always goes into scientific notation, but I left it there for consistency.
>
> That's an artifact of Perl internally converting ints to/from floats I guess.

Sounds like a good answer, but I question why it does the convert to begin with ... oh well, whatever, I got it to work.

>
> > $ perl t/02_same_schema.t
> > 1..76
> > sh: warning: setlocale: LC_ALL: cannot change locale (en): No such
> > file or directory
>
> LC_ALL=C should work, see README.dev (the new "env -i make test"
> should fix that as well).

Let's test the LC_ALL, here's the interesting parts:

$ get pull
# ...pulls in commit 8b60d0475d76c16a062b15ceccc743b3f497323f
# ...merges with my 2 changes for t/01_validate_range.t & t/02_dbstats.t

$ export LC_ALL=C

$ env | grep LC
LC_ALL=C

$ make distclean ; perl Makefile.PL ; make    # output ignored because it's normal

$ make test
PERL_DL_NONLAZY=1 /opt/perl/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00_basic.t ............... ok
...
t/02_autovac_freeze.t ...... sh: warning: setlocale: LC_ALL: cannot change locale (en): No such file or directory
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en): No such file or directory
Creating new symlink socket at /tmp/cptesting_socket
...
t/02_disk_space.t .......... skipped: Skipping disk_space tests because df does not work
...
t/02_same_schema.t ......... # Creating database in directory "test_database_check_postgres2"
sh: warning: setlocale: LC_ALL: cannot change locale (en): No such file or directory
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en): No such file or directory
Creating new symlink socket at /tmp/cptesting_socket2
# Creating database in directory "test_database_check_postgres3"
sh: warning: setlocale: LC_ALL: cannot change locale (en): No such file or directory
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en): No such file or directory
Creating new symlink socket at /tmp/cptesting_socket3
t/02_same_schema.t ......... ok
...
All tests successful.
Files=55, Tests=920, 271 wallclock secs ( 0.30 usr  0.06 sys + 62.88 cusr 13.19 csys = 76.43 CPU)
Result: PASS


So hey, other than some locale warnings I'm not sure about, we finally passed! :)

What's the opinion on the warnings? Should I be concerned?

The skip-failure on 02_disk_space.t is funny. The failure comes because my id can't read 1 partition. I'd have to be root or postgres because it is for Pg:
        df: `/db/9.5/data/pg_stat_tmp': Permission denied
That causes df to exit with 1. Otherwise, df works just fine. So you really should change the test to look at the output and try to ignore that part and use the output of df, even if you got a return code of 1.

Note: I'm running this all as me and not as some privileged user like "postres" or "root".

>
> > #     "search_path" is not set on all databases:
> > #       Exists on:  1
> > #       Missing on: 2, 3
> > #
> > # '
> > #     doesn't match '(?^:^POSTGRES_SAME_SCHEMA OK)'
> >
> > And so on and so on for 73 more tests. Based on the error, are you assuming that "search_path" won't be set? If so, then you need to unset it or set it to what you need for the session only. I'd offer a patch but I'm not sure what the test program is expecting.
>
> Does that prevail if you "make clean" first? The test databases are only created once and might not be up to date if something went wrong in earlier runs.

I'd really like to hope that the last test is a dummy and drops the DB created for the test, so it's all clean at the end and ready for the next run (I haven't looked though).

I suppose the real question is does the app work. :) I think it does. Kinda hard to tell because the output isn't really meant for humans. Still, I can see useful data from it if I parse the output just right and we are trying to get Nagios going, so it'll be even more useful then.

So with the 2 patches I've already sent you plus what's in HEAD, it now works for me. :)

Thanks for the app and for the help! I hope the feedback has been useful.
Kevin
This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, distribution, review, copy or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify us by reply e-mail, and destroy the original transmission and its attachments without reading them or saving them to disk. Thank you.