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

Commit7900e94

Browse files
committed
Fix pg_receivexlog --slot so that it doesn't prevent the server shutdown.
When pg_receivexlog --slot is connecting to the server, at the shutdownof the server, walsender keeps waiting for the last WAL record to bereplicated and flushed in pg_receivexlog. But previously pg_receivexlogissued sync command only when WAL file was switched. So there wasthe case where the last WAL was never flushed and walsender had tokeep waiting infinitely. This caused the server shutdown to get stuck.pg_recvlogical handles this problem by calling fsync() when it receivesthe request of immediate reply from the server. That is, at shutdown,walsender sends the request, pg_recvlogical receives it, flushes the lastWAL record, and sends the flush location back to the server. Sincewalsender can see that the last WAL record is successfully flushed, it canexit cleanly.This commit introduces the same logic as pg_recvlogical has,to pg_receivexlog.Back-patch to 9.4 where pg_receivexlog was changed so that it can usethe replication slot.Original patch by Michael Paquier, rewritten by me.Bug report by Furuya Osamu.
1 parente1ab2fa commit7900e94

File tree

1 file changed

+19
-0
lines changed

1 file changed

+19
-0
lines changed

‎src/bin/pg_basebackup/receivelog.c

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -918,6 +918,25 @@ HandleCopyStream(PGconn *conn, XLogRecPtr startpos, uint32 timeline,
918918
/* If the server requested an immediate reply, send one. */
919919
if (replyRequested&&still_sending)
920920
{
921+
if (reportFlushPosition&&lastFlushPosition<blockpos&&
922+
walfile!=1)
923+
{
924+
/*
925+
* If a valid flush location needs to be reported,
926+
* flush the current WAL file so that the latest flush
927+
* location is sent back to the server. This is necessary to
928+
* see whether the last WAL data has been successfully
929+
* replicated or not, at the normal shutdown of the server.
930+
*/
931+
if (fsync(walfile)!=0)
932+
{
933+
fprintf(stderr,_("%s: could not fsync file \"%s\": %s\n"),
934+
progname,current_walfile_name,strerror(errno));
935+
gotoerror;
936+
}
937+
lastFlushPosition=blockpos;
938+
}
939+
921940
now=feGetCurrentTimestamp();
922941
if (!sendFeedback(conn,blockpos,now, false))
923942
gotoerror;

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp