bug/oversight in TestLib.pm and PostgresNode.pm
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t36307psql -h localhost -U postgresBuilt from patchset v3 (message #3), July 28, 2026 at 07:45 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t36307_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t36307_3 && git checkout t36307_3Patchset v3 (message #3) is on t36307_3
I am trying to re-create pgbench-over-logical-replication as a TAP-test.
(the wisdom of that might be doubted, and I appreciate comments on it
too, but it's really another subject).
While trying to test pgbench's stderr (looking for 'creating tables' in
output of the initialisation step) I ran into these two bugs (or
perhaps better 'oversights').
But especially the omission of command_fails_like() in PostgresNode.pm
feels like an bug.
In the end it was necessary to change TestLib.pm's command_like()
because command_fails_like() also checks for a non-zero return value
(which seems to make sense, but in this case not possible: pgbench
returns 0 on init with output on stderr).
make check-world passes without error
Thanks,
Erik Rijkers
On Thu, Mar 23, 2017 at 12:51 AM, Erik Rijkers <er@xs4all.nl> wrote:
While trying to test pgbench's stderr (looking for 'creating tables' in
output of the initialisation step) I ran into these two bugs (or perhaps
better 'oversights').
+ if (defined $expected_stderr) {
+ like($stderr, $expected_stderr, "$test_name: stderr matches");
+ }
+ else {
is($stderr, '', "$test_name: no stderr");
- like($stdout, $expected_stdout, "$test_name: matches");
+ }
To simplify that you could as well set expected_output to be an empty
string, and just use like() instead of is(), saving this if/else.But especially the omission of command_fails_like() in PostgresNode.pm feels
like an bug.
+=item $node->command_fails_like(...) - TestLib::command_fails_like
with our PGPORT
+
+See command_ok(...)
+
+=cut
+
+sub command_fails_like
+{
+ my $self = shift;
+
+ local $ENV{PGPORT} = $self->port;
+
+ TestLib::command_fails_like(@_);
+}
Most likely a case where this is needed has not showed up, so +1 to
remove this inconsistency across the modules.
--
Michael--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-03-23 03:28, Michael Paquier wrote:
On Thu, Mar 23, 2017 at 12:51 AM, Erik Rijkers <er@xs4all.nl> wrote:
While trying to test pgbench's stderr (looking for 'creating tables'
in
output of the initialisation step) I ran into these two bugs (or
perhaps
better 'oversights').+ if (defined $expected_stderr) { + like($stderr, $expected_stderr, "$test_name: stderr matches"); + } + else { is($stderr, '', "$test_name: no stderr"); - like($stdout, $expected_stdout, "$test_name: matches"); + } To simplify that you could as well set expected_output to be an empty string, and just use like() instead of is(), saving this if/else.
(I'll assume you meant '$expected_stderr' (not 'expected_output'))
That would be nice but with that, other tests start complaining:
"doesn't look like a regex to me"
To avoid that, I uglified your version back to:
+ like($stderr, (defined $expected_stderr ? $expected_stderr :
qr{}),
+ "$test_name: stderr matches");I did it like that in the attached patch
(0001-testlib-like-stderr.diff).
The other (PostgresNode.pm.diff) is unchanged.
make check-world without error.
Thanks,
Erik Rijkers
On 3/22/17 11:51, Erik Rijkers wrote:
While trying to test pgbench's stderr (looking for 'creating tables' in
output of the initialisation step) I ran into these two bugs (or
perhaps better 'oversights').
Perhaps pgbench should be printing progress messages to stdout instead?
But especially the omission of command_fails_like() in PostgresNode.pm
feels like an bug.
Yeah, that's just because no one has needed it yet.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers