Skip to content

Commit 70291a3

Browse files
committed
Improve handling of empty query results in BackgroundPsql::query()
A newline is not added at the end of an empty query result, causing the banner of the hardcoded \echo to not be discarded. This would reflect on scripts that expect an empty result by showing the "QUERY_SEPARATOR" in the output returned back to the caller, which was confusing. This commit changes BackgroundPsql::query() so as empty results are able to work correctly, making the first newline before the banner optional, bringing more flexibility. Note that this change affects 037_invalid_database.pl, where three queries generated an empty result, with the script relying on the data from the hardcoded banner to exist in the expected output. These queries are changed to use query_safe(), leading to a simpler script. The author has also proposed a test in a different patch where empty results would exist when using BackgroundPsql. Author: Jacob Champion Reviewed-by: Andrew Dunstan, Michael Paquier Discussion: https://postgr.es/m/CAOYmi+=60deN20WDyCoHCiecgivJxr=98s7s7-C8SkXwrCfHXg@mail.gmail.com
1 parent f638aaf commit 70291a3

File tree

2 files changed

+9
-11
lines changed

2 files changed

+9
-11
lines changed

src/test/perl/PostgreSQL/Test/BackgroundPsql.pm

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -236,8 +236,10 @@ sub query
236236
die "psql query timed out" if $self->{timeout}->is_expired;
237237
$output = $self->{stdout};
238238

239-
# remove banner again, our caller doesn't care
240-
$output =~ s/\n$banner\n$//s;
239+
# Remove banner again, our caller doesn't care. The first newline is
240+
# optional, as there would not be one if consuming an empty query
241+
# result.
242+
$output =~ s/\n?$banner\n$//s;
241243

242244
# clear out output for the next query
243245
$self->{stdout} = '';

src/test/recovery/t/037_invalid_database.pl

Lines changed: 5 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -96,13 +96,12 @@
9696
my $pid = $bgpsql->query('SELECT pg_backend_pid()');
9797

9898
# create the database, prevent drop database via lock held by a 2PC transaction
99-
ok( $bgpsql->query_safe(
100-
qq(
99+
$bgpsql->query_safe(
100+
qq(
101101
CREATE DATABASE regression_invalid_interrupt;
102102
BEGIN;
103103
LOCK pg_tablespace;
104-
PREPARE TRANSACTION 'lock_tblspc';)),
105-
"blocked DROP DATABASE completion");
104+
PREPARE TRANSACTION 'lock_tblspc';));
106105

107106
# Try to drop. This will wait due to the still held lock.
108107
$bgpsql->query_until(qr//, "DROP DATABASE regression_invalid_interrupt;\n");
@@ -135,11 +134,8 @@
135134

136135
# To properly drop the database, we need to release the lock previously preventing
137136
# doing so.
138-
ok($bgpsql->query_safe(qq(ROLLBACK PREPARED 'lock_tblspc')),
139-
"unblock DROP DATABASE");
140-
141-
ok($bgpsql->query(qq(DROP DATABASE regression_invalid_interrupt)),
142-
"DROP DATABASE invalid_interrupt");
137+
$bgpsql->query_safe(qq(ROLLBACK PREPARED 'lock_tblspc'));
138+
$bgpsql->query_safe(qq(DROP DATABASE regression_invalid_interrupt));
143139

144140
$bgpsql->quit();
145141

0 commit comments

Comments
 (0)