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

Commit11abea3

Browse files
committed
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 isnot replayed, such WAL senders would remain in a "catchup" state, whichis inconsistent with the physical cousin.This can be easily reproduced by for example using pg_recvlogical andrestarting the upstream server. The TAP tests have been slightlymodified to detect the failure and strengthened so as future tests alsomake sure that a node is in streaming state when waiting for itscatchup.Backpatch down to 9.4 where this code has been introduced.Reported-by: Sawada MasahikoAuthor: Simon Riggs, Sawada MasahikoReviewed-by: Petr Jelinek, Michael Paquier, Vaishnavi PrabakaranDiscussion:https://postgr.es/m/CAD21AoB2ZbCCqOx=bgKMcLrAvs1V0ZMqzs7wBTuDySezTGtMZA@mail.gmail.com
1 parentc350320 commit11abea3

File tree

1 file changed

+15
-5
lines changed

1 file changed

+15
-5
lines changed

‎src/backend/replication/walsender.c‎

Lines changed: 15 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -2168,7 +2168,7 @@ WalSndLoop(WalSndSendDataCallback send_data)
21682168
if (MyWalSnd->state==WALSNDSTATE_CATCHUP)
21692169
{
21702170
ereport(DEBUG1,
2171-
(errmsg("standby\"%s\" has now caught up withprimary",
2171+
(errmsg("\"%s\" has now caught up withupstream server",
21722172
application_name)));
21732173
WalSndSetState(WALSNDSTATE_STREAMING);
21742174
}
@@ -2757,10 +2757,10 @@ XLogSendLogical(void)
27572757
char*errm;
27582758

27592759
/*
2760-
* Don't know whether we've caught up yet. We'll setit to true in
2761-
* WalSndWaitForWal, if we're actually waiting. We also set to true if
2762-
* XLogReadRecord() had to stop reading but WalSndWaitForWal didn't wait -
2763-
* i.e. when we're shutting down.
2760+
* Don't know whether we've caught up yet. We'll setWalSndCaughtUp to
2761+
*true inWalSndWaitForWal, if we're actually waiting. We also set to
2762+
*true ifXLogReadRecord() had to stop reading but WalSndWaitForWal
2763+
*didn't wait -i.e. when we're shutting down.
27642764
*/
27652765
WalSndCaughtUp= false;
27662766

@@ -2773,6 +2773,9 @@ XLogSendLogical(void)
27732773

27742774
if (record!=NULL)
27752775
{
2776+
/* XXX: Note that logical decoding cannot be used while in recovery */
2777+
XLogRecPtrflushPtr=GetFlushRecPtr();
2778+
27762779
/*
27772780
* Note the lack of any call to LagTrackerWrite() which is handled by
27782781
* WalSndUpdateProgress which is called by output plugin through
@@ -2781,6 +2784,13 @@ XLogSendLogical(void)
27812784
LogicalDecodingProcessRecord(logical_decoding_ctx,logical_decoding_ctx->reader);
27822785

27832786
sentPtr=logical_decoding_ctx->reader->EndRecPtr;
2787+
2788+
/*
2789+
* If we have sent a record that is at or beyond the flushed point, we
2790+
* have caught up.
2791+
*/
2792+
if (sentPtr >=flushPtr)
2793+
WalSndCaughtUp= true;
27842794
}
27852795
else
27862796
{

0 commit comments

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