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

Commitb170ca0

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 parent25d1ef1 commitb170ca0

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
@@ -1511,8 +1511,10 @@ sub poll_query_until
15111511

15121512
$stdout =~s/\r\n/\n/gif$Config{osname}eq'msys';
15131513
chomp($stdout);
1514+
$stderr =~s/\r\n/\n/gif$Config{osname}eq'msys';
1515+
chomp($stderr);
15141516

1515-
if ($stdouteq$expected)
1517+
if ($stdouteq$expected &&$stderreq'')
15161518
{
15171519
return 1;
15181520
}
@@ -1525,8 +1527,6 @@ sub poll_query_until
15251527

15261528
# The query result didn't change in 180 seconds. Give up. Print the
15271529
# output from the last attempt, hopefully that's useful for debugging.
1528-
$stderr =~s/\r\n/\n/gif$Config{osname}eq'msys';
1529-
chomp($stderr);
15301530
diagqq(poll_query_until timed out executing this query:
15311531
$query
15321532
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
@@ -213,7 +209,7 @@
213209
$monitor->finish;
214210

215211
# Wait till server restarts
216-
is($node->poll_query_until('postgres','SELECT 1','1'),
212+
is($node->poll_query_until('postgres',undef,''),
217213
"1","reconnected after SIGKILL");
218214

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

0 commit comments

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