Fix WAL replay of truncate operations to cope with the possibility that the

truncated relation was deleted later in the WAL sequence.  Since replay
normally auto-creates a relation upon its first reference by a WAL log entry,
failure is seen only if the truncate entry happens to be the first reference
after the checkpoint we're restarting from; which is a pretty unusual case but
of course not impossible.  Fix by making truncate entries auto-create like
the other ones do.  Per report and test case from Dharmendra Goyal.

1 files changed, 9 insertions, 1 deletions

diff --git a/src/backend/storage/smgr/smgr.c b/src/backend/storage/smgr/smgr.c
index 0c88bbfcc7f..8b0bee82153 100644
--- a/src/backend/storage/smgr/smgr.c
+++ b/src/backend/storage/smgr/smgr.c
@@ -11,7 +11,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/storage/smgr/smgr.c,v 1.85 2005/01/10 20:02:22 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/storage/smgr/smgr.c,v 1.85.4.1 2007/07/20 16:30:12 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -874,6 +874,14 @@ smgr_redo(XLogRecPtr lsn, XLogRecord *record)
 		reln = smgropen(xlrec->rnode);
 
 		/*
+		 * Forcibly create relation if it doesn't exist (which suggests that
+		 * it was dropped somewhere later in the WAL sequence).  As in
+		 * XLogOpenRelation, we prefer to recreate the rel and replay the
+		 * log as best we can until the drop is seen.
+		 */
+		smgrcreate(reln, false, true);
+
+		/*
 		 * First, force bufmgr to drop any buffers it has for the to-be-
 		 * truncated blocks.  We must do this, else subsequent
 		 * XLogReadBuffer operations will not re-extend the file properly.