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

Commit596ba75

Browse files
committed
Fix issue with WAL archiving in standby.
Previously, walreceiver always closed the currently-opened WAL segmentand created its archive notification file, after it finished writingthe current segment up and received any WAL data that should bewritten into the next segment. If walreceiver exited just beforeany WAL data in the next segment arrived at standby, it did notcreate the archive notification file of the current segmenteven though that's known completed. This behavior could causeWAL archiving of the segment to be delayed until subsequentrestartpoints or checkpoints created its notification file.To fix the issue, this commit changes walreceiver so that it createsan archive notification file of a current WAL segment immediatelyif that's known completed before receiving next WAL data.Back-patch to all supported branches.Reported-by: Kyotaro HoriguchiAuthor: Fujii MasaoReviewed-by: Kyotaro HoriguchiDiscussion:https://postgr.es/m/20200630.165503.1465894182551545886.horikyota.ntt@gmail.com
1 parent0ffbe90 commit596ba75

File tree

1 file changed

+61
-35
lines changed

1 file changed

+61
-35
lines changed

‎src/backend/replication/walreceiver.c

Lines changed: 61 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -125,6 +125,7 @@ static void WalRcvDie(int code, Datum arg);
125125
staticvoidXLogWalRcvProcessMsg(unsignedchartype,char*buf,Sizelen);
126126
staticvoidXLogWalRcvWrite(char*buf,Sizenbytes,XLogRecPtrrecptr);
127127
staticvoidXLogWalRcvFlush(booldying);
128+
staticvoidXLogWalRcvClose(XLogRecPtrrecptr);
128129
staticvoidXLogWalRcvSendReply(boolforce,boolrequestReply);
129130
staticvoidXLogWalRcvSendHSFeedback(boolimmed);
130131
staticvoidProcessWalSndrMessage(XLogRecPtrwalEnd,TimestampTzsendTime);
@@ -883,42 +884,12 @@ XLogWalRcvWrite(char *buf, Size nbytes, XLogRecPtr recptr)
883884
{
884885
intsegbytes;
885886

886-
if (recvFile<0|| !XLByteInSeg(recptr,recvSegNo,wal_segment_size))
887-
{
888-
/*
889-
* fsync() and close current file before we switch to next one. We
890-
* would otherwise have to reopen this file to fsync it later
891-
*/
892-
if (recvFile >=0)
893-
{
894-
charxlogfname[MAXFNAMELEN];
895-
896-
XLogWalRcvFlush(false);
897-
898-
XLogFileName(xlogfname,recvFileTLI,recvSegNo,wal_segment_size);
899-
900-
/*
901-
* XLOG segment files will be re-read by recovery in startup
902-
* process soon, so we don't advise the OS to release cache
903-
* pages associated with the file like XLogFileClose() does.
904-
*/
905-
if (close(recvFile)!=0)
906-
ereport(PANIC,
907-
(errcode_for_file_access(),
908-
errmsg("could not close log segment %s: %m",
909-
xlogfname)));
910-
911-
/*
912-
* Create .done file forcibly to prevent the streamed segment
913-
* from being archived later.
914-
*/
915-
if (XLogArchiveMode!=ARCHIVE_MODE_ALWAYS)
916-
XLogArchiveForceDone(xlogfname);
917-
else
918-
XLogArchiveNotify(xlogfname);
919-
}
920-
recvFile=-1;
887+
/* Close the current segment if it's completed */
888+
if (recvFile >=0&& !XLByteInSeg(recptr,recvSegNo,wal_segment_size))
889+
XLogWalRcvClose(recptr);
921890

891+
if (recvFile<0)
892+
{
922893
/* Create/use new log file */
923894
XLByteToSeg(recptr,recvSegNo,wal_segment_size);
924895
recvFile=XLogFileInit(recvSegNo);
@@ -967,6 +938,15 @@ XLogWalRcvWrite(char *buf, Size nbytes, XLogRecPtr recptr)
967938

968939
/* Update shared-memory status */
969940
pg_atomic_write_u64(&WalRcv->writtenUpto,LogstreamResult.Write);
941+
942+
/*
943+
* Close the current segment if it's fully written up in the last cycle of
944+
* the loop, to create its archive notification file soon. Otherwise WAL
945+
* archiving of the segment will be delayed until any data in the next
946+
* segment is received and written.
947+
*/
948+
if (recvFile >=0&& !XLByteInSeg(recptr,recvSegNo,wal_segment_size))
949+
XLogWalRcvClose(recptr);
970950
}
971951

972952
/*
@@ -1020,6 +1000,52 @@ XLogWalRcvFlush(bool dying)
10201000
}
10211001
}
10221002

1003+
/*
1004+
* Close the current segment.
1005+
*
1006+
* Flush the segment to disk before closing it. Otherwise we have to
1007+
* reopen and fsync it later.
1008+
*
1009+
* Create an archive notification file since the segment is known completed.
1010+
*/
1011+
staticvoid
1012+
XLogWalRcvClose(XLogRecPtrrecptr)
1013+
{
1014+
charxlogfname[MAXFNAMELEN];
1015+
1016+
Assert(recvFile >=0&& !XLByteInSeg(recptr,recvSegNo,wal_segment_size));
1017+
1018+
/*
1019+
* fsync() and close current file before we switch to next one. We would
1020+
* otherwise have to reopen this file to fsync it later
1021+
*/
1022+
XLogWalRcvFlush(false);
1023+
1024+
XLogFileName(xlogfname,recvFileTLI,recvSegNo,wal_segment_size);
1025+
1026+
/*
1027+
* XLOG segment files will be re-read by recovery in startup process soon,
1028+
* so we don't advise the OS to release cache pages associated with the
1029+
* file like XLogFileClose() does.
1030+
*/
1031+
if (close(recvFile)!=0)
1032+
ereport(PANIC,
1033+
(errcode_for_file_access(),
1034+
errmsg("could not close log segment %s: %m",
1035+
xlogfname)));
1036+
1037+
/*
1038+
* Create .done file forcibly to prevent the streamed segment from being
1039+
* archived later.
1040+
*/
1041+
if (XLogArchiveMode!=ARCHIVE_MODE_ALWAYS)
1042+
XLogArchiveForceDone(xlogfname);
1043+
else
1044+
XLogArchiveNotify(xlogfname);
1045+
1046+
recvFile=-1;
1047+
}
1048+
10231049
/*
10241050
* Send reply message to primary, indicating our current WAL locations, oldest
10251051
* xmin and the current time.

0 commit comments

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