Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit94e2102

Browse files
committed
Restore robustness of TAP tests that wait for postmaster restart.
Several TAP tests use poll_query_until() to wait for the postmasterto restart. They were checking to see if a trivial query(e.g. "SELECT 1") succeeds. However, that's problematic in the wakeof commit11e9caf, because now that we feed said query to psqlvia stdin, we risk IPC::Run whining about a SIGPIPE failure if psqlquits before reading the query. Hence, we can't use a nonemptyquery in cases where we need to wait for connection failures tostop happening.Per the precedent of commitsc757a3d and6d41dd0, we can pass"undef" as the query in such cases to ensure that IPC::Run hasnothing to write. However, then we have to say that the expectedoutput is empty, and this exposes a deficiency in poll_query_until:if psql fails altogether and returns empty stdout, poll_query_untilwill treat that as a success! That's because, contrary to itsdocumentation, it makes no actual check for psql failure, lookingneither at the exit status nor at stderr.To fix that, adjust poll_query_until to insist on empty stderr aswell as a stdout match. (I experimented with checking exit statusinstead, but it seems that psql often does exit(1) in cases that weneed to consider successes. That might be something to fix someday,but it would be a non-back-patchable behavior change.)Back-patch to v10. The test cases needing this exist only as farback as v11, but it seems wise to keep poll_query_until's behaviorthe same in v10, in case we back-patch another such test case infuture. (9.6 does not currently need this change, because in thatbranch poll_query_until can't be told to accept empty stdout asa success case.)Per assorted buildfarm failures, mostly on hoverfly.Discussion:https://postgr.es/m/CAA4eK1+zM6L4QSA1XMvXY_qqWwdUmqkOS1+hWvL8QcYEBGA1Uw@mail.gmail.com
1 parentf479ea9 commit94e2102

File tree

2 files changed

+6
-10
lines changed

2 files changed

+6
-10
lines changed

‎src/test/perl/PostgresNode.pm

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1668,8 +1668,10 @@ sub poll_query_until
16681668

16691669
$stdout =~s/\r\n/\n/gif$Config{osname}eq'msys';
16701670
chomp($stdout);
1671+
$stderr =~s/\r\n/\n/gif$Config{osname}eq'msys';
1672+
chomp($stderr);
16711673

1672-
if ($stdouteq$expected)
1674+
if ($stdouteq$expected &&$stderreq'')
16731675
{
16741676
return 1;
16751677
}
@@ -1682,8 +1684,6 @@ sub poll_query_until
16821684

16831685
# The query result didn't change in 180 seconds. Give up. Print the
16841686
# output from the last attempt, hopefully that's useful for debugging.
1685-
$stderr =~s/\r\n/\n/gif$Config{osname}eq'msys';
1686-
chomp($stderr);
16871687
diagqq(poll_query_until timed out executing this query:
16881688
$query
16891689
expecting this output:

‎src/test/recovery/t/013_crash_restart.pl

Lines changed: 3 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -134,12 +134,8 @@
134134
$monitor->finish;
135135

136136
# Wait till server restarts
137-
is($node->poll_query_until(
138-
'postgres',
139-
'SELECT $$restarted after sigquit$$;',
140-
'restarted after sigquit'),
141-
"1",
142-
"reconnected after SIGQUIT");
137+
is($node->poll_query_until('postgres',undef,''),
138+
"1","reconnected after SIGQUIT");
143139

144140

145141
# restart psql processes, now that the crash cycle finished
@@ -214,7 +210,7 @@
214210
$monitor->finish;
215211

216212
# Wait till server restarts
217-
is($node->poll_query_until('postgres','SELECT 1','1'),
213+
is($node->poll_query_until('postgres',undef,''),
218214
"1","reconnected after SIGKILL");
219215

220216
# Make sure the committed rows survived, in-progress ones not

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp