mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

If a corrupt WAL record is received by streaming replication, disconnect

Browse Source 
and retry. If the record is genuinely corrupt in the master database,
there's little hope of recovering, but it's better than simply retrying
to apply the corrupt WAL record in a tight loop without even trying to
retransmit it, which is what we used to do.
This commit is contained in:
Heikki Linnakangas 2010-06-14 06:04:21 +00:00
parent 38736e2276
commit 6da07cd80d
1 changed files with 17 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
src/backend/access/transam/xlog.c
View File

@ -7,7 +7,7 @@
* Portions Copyright (c) 1996-2010, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
* $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.423 2010/06/12 09:14:52 petere Exp $
* $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.424 2010/06/14 06:04:21 heikki Exp $
*
*-------------------------------------------------------------------------
*/
@ -9270,6 +9270,22 @@ retry:
{
if (WalRcvInProgress())
{
/*
* If we find an invalid record in the WAL streamed from
* master, something is seriously wrong. There's little
* chance that the problem will just go away, but PANIC
* is not good for availability either, especially in
* hot standby mode. Disconnect, and retry from
* archive/pg_xlog again. The WAL in the archive should
* be identical to what was streamed, so it's unlikely
* that it helps, but one can hope...
*/
if (failedSources & XLOG_FROM_STREAM)
{
ShutdownWalRcv();
continue;
}
/*
* While walreceiver is active, wait for new WAL to arrive
* from primary.