pgsql: Fix assorted portability issues in new pgbench TAP tests.
Fix assorted portability issues in new pgbench TAP tests.
* Our own version of getopt_long doesn't support abbreviation of
long options.
* It doesn't do automatic rearrangement of non-option arguments to the end,
either.
* Test was way too optimistic about the platform independence of
NaN and Infinity outputs. I rather imagine we might have to lose
those tests altogether, but for the moment just allow case variation
and fully spelled out Infinity.
Per buildfarm.
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/869aa40a27fa4908ad4112f1079bf732d1a12e13
Modified Files
--------------
src/bin/pgbench/t/001_pgbench_with_server.pl | 11 ++++-------
src/bin/pgbench/t/002_pgbench_no_server.pl | 2 +-
2 files changed, 5 insertions(+), 8 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Fix assorted portability issues in new pgbench TAP tests.
Most where hard to guess without having the report. Thanks.
* Test was way too optimistic about the platform independence of
NaN and Infinity outputs. I rather imagine we might have to lose
those tests altogether, but for the moment just allow case variation
and fully spelled out Infinity.
Yep. I've seen strange things on these. I wonder whether all test platform
are IEEE 754 conforming.
--
Fabien.
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Hello,
Please find attached "blind" additional fixes for Windows & AIX.
- more nan/inf variants
- different message on non existing user
- illegal vs unrecognized options
I suspect that $windows_os is not true on "bowerbird", in order to fix it
the value of "$Config{osname}" is needed...
--
Fabien.
Attachments:
pgbench-tap-fix-1.patchtext/x-diff; name=pgbench-tap-fix-1.patchDownload
diff --git a/src/bin/pgbench/t/001_pgbench_with_server.pl b/src/bin/pgbench/t/001_pgbench_with_server.pl
index 66df4bc..54a6039 100644
--- a/src/bin/pgbench/t/001_pgbench_with_server.pl
+++ b/src/bin/pgbench/t/001_pgbench_with_server.pl
@@ -73,7 +73,11 @@ pgbench(
1,
[qr{^$}],
[ qr{connection to database "template0" failed},
- qr{FATAL: role "no-such-user" does not exist} ],
+ # FATAL: role "no-such-user" does not exist
+ # FATAL: SSPI authentication failed for user "no-such-user"
+ qr{FATAL:.* (role|user) "no-such-user"},
+ qr{FATAL:.* (does not exist|authentication failed)}
+ ],
'no such user');
pgbench(
@@ -217,9 +221,9 @@ pgbench(
qr{command=18.: double 18\b},
qr{command=19.: double 19\b},
qr{command=20.: double 20\b},
- qr{command=21.: double -?nan}i,
- qr{command=22.: double inf}i,
- qr{command=23.: double -inf}i,
+ qr{command=21.: double (-?nan|-1\.#IND)}i,
+ qr{command=22.: double (inf|1\.#INF)}i,
+ qr{command=23.: double (-inf|-1\.#INF)}i,
qr{command=24.: int 9223372036854775807\b}, ],
'pgbench expressions',
{ '001_pgbench_expressions' => q{-- integer functions
diff --git a/src/bin/pgbench/t/002_pgbench_no_server.pl b/src/bin/pgbench/t/002_pgbench_no_server.pl
index 631aa73..d6b3d4f 100644
--- a/src/bin/pgbench/t/002_pgbench_no_server.pl
+++ b/src/bin/pgbench/t/002_pgbench_no_server.pl
@@ -26,7 +26,7 @@ my @options = (
# name, options, stderr checks
[ 'bad option',
'-h home -p 5432 -U calvin -d --bad-option',
- [ qr{unrecognized option}, qr{--help.*more information} ] ],
+ [ qr{(unrecognized|illegal) option}, qr{--help.*more information} ] ],
[ 'no file',
'-f no-such-file',
[qr{could not open file "no-such-file":}] ],
Fabien COELHO <coelho@cri.ensmp.fr> writes:
Please find attached "blind" additional fixes for Windows & AIX.
- more nan/inf variants
I think we should just drop this. It's not worth the trouble,
and I have no faith whatsoever that we've seen every behavior.
- different message on non existing user
Ditto. It's not only not worth the trouble, it's out of scope for
pgbench tests. A single connection-failure test case seems plenty
to me, and the no-such-database case is enough for that.
I suspect that $windows_os is not true on "bowerbird", in order to fix it
the value of "$Config{osname}" is needed...
I looked at sub psql and noted that it was disassembling the $? result
without any platform-specific hacks. So I've made command_checks_all
do likewise, and also notice crashes if any.
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers