diff options
| author | Michael Paquier <michael@paquier.xyz> | 2018-07-12 10:19:51 +0900 |
|---|---|---|
| committer | Michael Paquier <michael@paquier.xyz> | 2018-07-12 10:19:51 +0900 |
| commit | 0414ac6a1eb2e457c8019c5a558bd72b37dede89 (patch) | |
| tree | 6f89c7e1ba5a5781eb183ba9e531e1af828c1879 /src/test | |
| parent | 5b762d96e8c602434bc7e56f910c23c54e95f80d (diff) | |
| download | postgresql-0414ac6a1eb2e457c8019c5a558bd72b37dede89.tar.gz postgresql-0414ac6a1eb2e457c8019c5a558bd72b37dede89.zip | |
Make logical WAL sender report streaming state appropriately
WAL senders sending logically-decoded data fail to properly report in
"streaming" state when starting up, hence as long as one extra record is
not replayed, such WAL senders would remain in a "catchup" state, which
is inconsistent with the physical cousin.
This can be easily reproduced by for example using pg_recvlogical and
restarting the upstream server. The TAP tests have been slightly
modified to detect the failure and strengthened so as future tests also
make sure that a node is in streaming state when waiting for its
catchup.
Backpatch down to 9.4 where this code has been introduced.
Reported-by: Sawada Masahiko
Author: Simon Riggs, Sawada Masahiko
Reviewed-by: Petr Jelinek, Michael Paquier, Vaishnavi Prabakaran
Discussion: https://postgr.es/m/CAD21AoB2ZbCCqOx=bgKMcLrAvs1V0ZMqzs7wBTuDySezTGtMZA@mail.gmail.com
Diffstat (limited to 'src/test')
| -rw-r--r-- | src/test/perl/PostgresNode.pm | 5 | ||||
| -rw-r--r-- | src/test/subscription/t/001_rep_changes.pl | 5 |
2 files changed, 8 insertions, 2 deletions
diff --git a/src/test/perl/PostgresNode.pm b/src/test/perl/PostgresNode.pm index 5f848a0db7a..e60673ad723 100644 --- a/src/test/perl/PostgresNode.pm +++ b/src/test/perl/PostgresNode.pm @@ -1525,7 +1525,8 @@ also works for logical subscriptions) until its replication location in pg_stat_replication equals or passes the upstream's WAL insert point at the time this function is called. By default the replay_lsn is waited for, but 'mode' may be specified to wait for any of -sent|write|flush|replay. +sent|write|flush|replay. The connection catching up must be in a streaming +state. If there is no active replication connection from this peer, waits until poll_query_until timeout. @@ -1570,7 +1571,7 @@ sub wait_for_catchup . $lsn_expr . " on " . $self->name . "\n"; my $query = - qq[SELECT $lsn_expr <= ${mode}_lsn FROM pg_catalog.pg_stat_replication WHERE application_name = '$standby_name';]; + qq[SELECT $lsn_expr <= ${mode}_lsn AND state = 'streaming' FROM pg_catalog.pg_stat_replication WHERE application_name = '$standby_name';]; $self->poll_query_until('postgres', $query) or croak "timed out waiting for catchup"; print "done\n"; diff --git a/src/test/subscription/t/001_rep_changes.pl b/src/test/subscription/t/001_rep_changes.pl index 503556fd6cd..d94458e00e1 100644 --- a/src/test/subscription/t/001_rep_changes.pl +++ b/src/test/subscription/t/001_rep_changes.pl @@ -188,6 +188,11 @@ $node_publisher->safe_psql('postgres', "INSERT INTO tab_ins SELECT generate_series(1001,1100)"); $node_publisher->safe_psql('postgres', "DELETE FROM tab_rep"); +# Restart the publisher and check the state of the subscriber which +# should be in a streaming state after catching up. +$node_publisher->stop('fast'); +$node_publisher->start; + $node_publisher->wait_for_catchup($appname); $result = $node_subscriber->safe_psql('postgres', |