From: Heikki Linnakangas Date: Mon, 14 Jun 2010 06:04:21 +0000 (+0000) Subject: If a corrupt WAL record is received by streaming replication, disconnect X-Git-Tag: REL9_0_BETA3~117 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=6da07cd80dba3324feec2ee422b325d544e1be55;p=postgresql If a corrupt WAL record is received by streaming replication, disconnect 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. --- diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index a72d7f24da..5787b3d164 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -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.