Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
backport: Improve handling of empty query results in BackgroundPsql
authorAndres Freund <andres@anarazel.de>
Wed, 19 Feb 2025 14:39:49 +0000 (09:39 -0500)
committerAndres Freund <andres@anarazel.de>
Wed, 19 Feb 2025 14:52:32 +0000 (09:52 -0500)
This is a backport of 70291a3c66e. Originally it was only applied to master,
but I (Andres) am planning to fix a few bugs in BackgroundPsql that are harder
to fix in the backbranches with the old behavior. It's also generally good for
test infrastructure to behave similarly across branches, to avoid pain during
backpatching.  70291a3c66e changes the behavior in some cases, but after
discussing it, we are ok with that, it seems unlikely that there are
out-of-core tests relying on the prior behavior.

Discussion: https://postgr.es/m/ilcctzb5ju2gulvnadjmhgatnkxsdpac652byb2u3d3wqziyvx@fbuqcglker46

Michael's original commit message:

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

src/test/perl/PostgreSQL/Test/BackgroundPsql.pm
src/test/recovery/t/037_invalid_database.pl

index 9878bedef88e7cae04ed8f0755c81dc018e8c622..edb0057058e0d686c1d227cf3c1a969d13f66464 100644 (file)
@@ -222,8 +222,10 @@ sub query
    die "psql query timed out" if $self->{timeout}->is_expired;
    $output = $self->{stdout};
 
-   # remove banner again, our caller doesn't care
-   $output =~ s/\n$banner\n$//s;
+   # Remove banner again, our caller doesn't care.  The first newline is
+   # optional, as there would not be one if consuming an empty query
+   # result.
+   $output =~ s/\n?$banner\n$//s;
 
    # clear out output for the next query
    $self->{stdout} = '';
index 7e5e0bb31f969506db2a60605afc4f283d3b322e..69fcaaf0c3bdc52260ee3f52996cf97ebadbfc7c 100644 (file)
@@ -92,13 +92,12 @@ my $bgpsql = $node->background_psql('postgres', on_error_stop => 0);
 my $pid = $bgpsql->query('SELECT pg_backend_pid()');
 
 # create the database, prevent drop database via lock held by a 2PC transaction
-ok( $bgpsql->query_safe(
-       qq(
+$bgpsql->query_safe(
+   qq(
   CREATE DATABASE regression_invalid_interrupt;
   BEGIN;
   LOCK pg_tablespace;
-  PREPARE TRANSACTION 'lock_tblspc';)),
-   "blocked DROP DATABASE completion");
+  PREPARE TRANSACTION 'lock_tblspc';));
 
 # Try to drop. This will wait due to the still held lock.
 $bgpsql->query_until(qr//, "DROP DATABASE regression_invalid_interrupt;\n");
@@ -131,11 +130,8 @@ is($node->psql('regression_invalid_interrupt', ''),
 
 # To properly drop the database, we need to release the lock previously preventing
 # doing so.
-ok($bgpsql->query_safe(qq(ROLLBACK PREPARED 'lock_tblspc')),
-   "unblock DROP DATABASE");
-
-ok($bgpsql->query(qq(DROP DATABASE regression_invalid_interrupt)),
-   "DROP DATABASE invalid_interrupt");
+$bgpsql->query_safe(qq(ROLLBACK PREPARED 'lock_tblspc'));
+$bgpsql->query_safe(qq(DROP DATABASE regression_invalid_interrupt));
 
 $bgpsql->quit();