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

Commitb186523

Browse files
committed
Send status updates back from standby server to master, indicating how far
the standby has written, flushed, and applied the WAL. At the moment, thisis for informational purposes only, the values are only shown inpg_stat_replication system view, but in the future they will also be neededfor synchronous replication.Extracted from Simon riggs' synchronous replication patch by Robert Haas, withsome tweaking by me.
1 parent4c468b3 commitb186523

File tree

15 files changed

+352
-22
lines changed

15 files changed

+352
-22
lines changed

‎doc/src/sgml/config.sgml

Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1984,6 +1984,29 @@ SET ENABLE_SEQSCAN TO OFF;
19841984
</listitem>
19851985
</varlistentry>
19861986

1987+
<varlistentry id="guc-wal-receiver-status-interval" xreflabel="wal_receiver_status_interval">
1988+
<term><varname>wal_receiver_status_interval</varname> (<type>integer</type>)</term>
1989+
<indexterm>
1990+
<primary><varname>wal_receiver_status_interval</> configuration parameter</primary>
1991+
</indexterm>
1992+
<listitem>
1993+
<para>
1994+
Specifies the minimum frequency, in seconds, for the WAL receiver
1995+
process on the standby to send information about replication progress
1996+
to the primary, where they can be seen using the
1997+
<literal>pg_stat_replication</literal> view. The standby will report
1998+
the last transaction log position it has written, the last position it
1999+
has flushed to disk, and the last position it has applied. Updates are
2000+
sent each time the write or flush positions changed, or at least as
2001+
often as specified by this parameter. Thus, the apply position may
2002+
lag slightly behind the true position. Setting this parameter to zero
2003+
disables status updates completely. This parameter can only be set in
2004+
the <filename>postgresql.conf</> file or on the server command line.
2005+
The default value is 10 seconds.
2006+
</para>
2007+
</listitem>
2008+
</varlistentry>
2009+
19872010
<varlistentry id="guc-vacuum-defer-cleanup-age" xreflabel="vacuum_defer_cleanup_age">
19882011
<term><varname>vacuum_defer_cleanup_age</varname> (<type>integer</type>)</term>
19892012
<indexterm>

‎doc/src/sgml/monitoring.sgml

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -298,8 +298,11 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
298298
<entry><structname>pg_stat_replication</><indexterm><primary>pg_stat_replication</primary></indexterm></entry>
299299
<entry>One row per WAL sender process, showing process <acronym>ID</>,
300300
user OID, user name, application name, client's address and port number,
301-
time at which the server process began execution, current WAL sender
302-
state and transaction log location. The columns detailing what exactly
301+
time at which the server process began execution, and the current WAL
302+
sender state and transaction log location. In addition, the standby
303+
reports the last transaction log position it received and wrote, the last
304+
position it flushed to disk, and the last position it replayed, and this
305+
information is also displayed here. The columns detailing what exactly
303306
the connection is doing are only visible if the user examining the view
304307
is a superuser.
305308
</entry>

‎doc/src/sgml/protocol.sgml

Lines changed: 76 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1469,6 +1469,82 @@ The commands accepted in walsender mode are:
14691469
shutdown), it will send a CommandComplete message before exiting.
14701470
This might not happen during an abnormal shutdown, of course.
14711471
</para>
1472+
1473+
<para>
1474+
The receiving process can send a status update back to the sender at
1475+
any time, using the following message format (also in the payload of
1476+
a CopyData message):
1477+
</para>
1478+
1479+
<para>
1480+
<variablelist>
1481+
<varlistentry>
1482+
<term>
1483+
Standby status update (F)
1484+
</term>
1485+
<listitem>
1486+
<para>
1487+
<variablelist>
1488+
<varlistentry>
1489+
<term>
1490+
Byte1('r')
1491+
</term>
1492+
<listitem>
1493+
<para>
1494+
Identifies the message as a receiver status update.
1495+
</para>
1496+
</listitem>
1497+
</varlistentry>
1498+
<varlistentry>
1499+
<term>
1500+
Byte8
1501+
</term>
1502+
<listitem>
1503+
<para>
1504+
The location of the last WAL byte + 1 received and written to disk
1505+
in the standby, in XLogRecPtr format.
1506+
</para>
1507+
</listitem>
1508+
</varlistentry>
1509+
<varlistentry>
1510+
<term>
1511+
Byte8
1512+
</term>
1513+
<listitem>
1514+
<para>
1515+
The location of the last WAL byte + 1 flushed to disk in
1516+
the standby, in XLogRecPtr format.
1517+
</para>
1518+
</listitem>
1519+
</varlistentry>
1520+
<varlistentry>
1521+
<term>
1522+
Byte8
1523+
</term>
1524+
<listitem>
1525+
<para>
1526+
The location of the last WAL byte + 1 applied in the standby, in
1527+
XLogRecPtr format.
1528+
</para>
1529+
</listitem>
1530+
</varlistentry>
1531+
<varlistentry>
1532+
<term>
1533+
Byte8
1534+
</term>
1535+
<listitem>
1536+
<para>
1537+
The server's system clock at the time of transmission,
1538+
given in TimestampTz format.
1539+
</para>
1540+
</listitem>
1541+
</varlistentry>
1542+
</variablelist>
1543+
</para>
1544+
</listitem>
1545+
</varlistentry>
1546+
</variablelist>
1547+
</para>
14721548
</listitem>
14731549
</varlistentry>
14741550

‎src/backend/access/transam/xlog.c

Lines changed: 20 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -9317,6 +9317,25 @@ pg_last_xlog_receive_location(PG_FUNCTION_ARGS)
93179317
PG_RETURN_TEXT_P(cstring_to_text(location));
93189318
}
93199319

9320+
/*
9321+
* Get latest redo apply position.
9322+
*
9323+
* Exported to allow WALReceiver to read the pointer directly.
9324+
*/
9325+
XLogRecPtr
9326+
GetXLogReplayRecPtr(void)
9327+
{
9328+
/* use volatile pointer to prevent code rearrangement */
9329+
volatileXLogCtlData*xlogctl=XLogCtl;
9330+
XLogRecPtrrecptr;
9331+
9332+
SpinLockAcquire(&xlogctl->info_lck);
9333+
recptr=xlogctl->recoveryLastRecPtr;
9334+
SpinLockRelease(&xlogctl->info_lck);
9335+
9336+
returnrecptr;
9337+
}
9338+
93209339
/*
93219340
* Report the last WAL replay location (same format as pg_start_backup etc)
93229341
*
@@ -9326,14 +9345,10 @@ pg_last_xlog_receive_location(PG_FUNCTION_ARGS)
93269345
Datum
93279346
pg_last_xlog_replay_location(PG_FUNCTION_ARGS)
93289347
{
9329-
/* use volatile pointer to prevent code rearrangement */
9330-
volatileXLogCtlData*xlogctl=XLogCtl;
93319348
XLogRecPtrrecptr;
93329349
charlocation[MAXFNAMELEN];
93339350

9334-
SpinLockAcquire(&xlogctl->info_lck);
9335-
recptr=xlogctl->recoveryLastRecPtr;
9336-
SpinLockRelease(&xlogctl->info_lck);
9351+
recptr=GetXLogReplayRecPtr();
93379352

93389353
if (recptr.xlogid==0&&recptr.xrecoff==0)
93399354
PG_RETURN_NULL();

‎src/backend/catalog/system_views.sql

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -509,7 +509,10 @@ CREATE VIEW pg_stat_replication AS
509509
S.client_port,
510510
S.backend_start,
511511
W.state,
512-
W.sent_location
512+
W.sent_location,
513+
W.write_location,
514+
W.flush_location,
515+
W.apply_location
513516
FROM pg_stat_get_activity(NULL)AS S, pg_authid U,
514517
pg_stat_get_wal_senders()AS W
515518
WHERES.usesysid=U.oidAND

‎src/backend/replication/walreceiver.c

Lines changed: 72 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -54,6 +54,9 @@
5454
/* Global variable to indicate if this process is a walreceiver process */
5555
boolam_walreceiver;
5656

57+
/* GUC variable */
58+
intwal_receiver_status_interval;
59+
5760
/* libpqreceiver hooks to these when loaded */
5861
walrcv_connect_typewalrcv_connect=NULL;
5962
walrcv_receive_typewalrcv_receive=NULL;
@@ -88,6 +91,8 @@ static struct
8891
XLogRecPtrFlush;/* last byte + 1 flushed in the standby */
8992
}LogstreamResult;
9093

94+
staticStandbyReplyMessagereply_message;
95+
9196
/*
9297
* About SIGTERM handling:
9398
*
@@ -114,6 +119,7 @@ static void WalRcvDie(int code, Datum arg);
114119
staticvoidXLogWalRcvProcessMsg(unsignedchartype,char*buf,Sizelen);
115120
staticvoidXLogWalRcvWrite(char*buf,Sizenbytes,XLogRecPtrrecptr);
116121
staticvoidXLogWalRcvFlush(void);
122+
staticvoidXLogWalRcvSendReply(void);
117123

118124
/* Signal handlers */
119125
staticvoidWalRcvSigHupHandler(SIGNAL_ARGS);
@@ -306,12 +312,23 @@ WalReceiverMain(void)
306312
while (walrcv_receive(0,&type,&buf,&len))
307313
XLogWalRcvProcessMsg(type,buf,len);
308314

315+
/* Let the master know that we received some data. */
316+
XLogWalRcvSendReply();
317+
309318
/*
310319
* If we've written some records, flush them to disk and let the
311320
* startup process know about them.
312321
*/
313322
XLogWalRcvFlush();
314323
}
324+
else
325+
{
326+
/*
327+
* We didn't receive anything new, but send a status update to
328+
* the master anyway, to report any progress in applying WAL.
329+
*/
330+
XLogWalRcvSendReply();
331+
}
315332
}
316333
}
317334

@@ -546,5 +563,60 @@ XLogWalRcvFlush(void)
546563
LogstreamResult.Write.xrecoff);
547564
set_ps_display(activitymsg, false);
548565
}
566+
567+
/* Also let the master know that we made some progress */
568+
XLogWalRcvSendReply();
549569
}
550570
}
571+
572+
/*
573+
* Send reply message to primary, indicating our current XLOG positions and
574+
* the current time.
575+
*/
576+
staticvoid
577+
XLogWalRcvSendReply(void)
578+
{
579+
charbuf[sizeof(StandbyReplyMessage)+1];
580+
TimestampTznow;
581+
582+
/*
583+
* If the user doesn't want status to be reported to the master, be sure
584+
* to exit before doing anything at all.
585+
*/
586+
if (wal_receiver_status_interval <=0)
587+
return;
588+
589+
/* Get current timestamp. */
590+
now=GetCurrentTimestamp();
591+
592+
/*
593+
* We can compare the write and flush positions to the last message we
594+
* sent without taking any lock, but the apply position requires a spin
595+
* lock, so we don't check that unless something else has changed or 10
596+
* seconds have passed. This means that the apply log position will
597+
* appear, from the master's point of view, to lag slightly, but since
598+
* this is only for reporting purposes and only on idle systems, that's
599+
* probably OK.
600+
*/
601+
if (XLByteEQ(reply_message.write,LogstreamResult.Write)
602+
&&XLByteEQ(reply_message.flush,LogstreamResult.Flush)
603+
&& !TimestampDifferenceExceeds(reply_message.sendTime,now,
604+
wal_receiver_status_interval*1000))
605+
return;
606+
607+
/* Construct a new message. */
608+
reply_message.write=LogstreamResult.Write;
609+
reply_message.flush=LogstreamResult.Flush;
610+
reply_message.apply=GetXLogReplayRecPtr();
611+
reply_message.sendTime=now;
612+
613+
elog(DEBUG2,"sending write %X/%X flush %X/%X apply %X/%X",
614+
reply_message.write.xlogid,reply_message.write.xrecoff,
615+
reply_message.flush.xlogid,reply_message.flush.xrecoff,
616+
reply_message.apply.xlogid,reply_message.apply.xrecoff);
617+
618+
/* Prepend with the message type and send it. */
619+
buf[0]='r';
620+
memcpy(&buf[1],&reply_message,sizeof(StandbyReplyMessage));
621+
walrcv_send(buf,sizeof(StandbyReplyMessage)+1);
622+
}

0 commit comments

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