1
0
mirror of https://github.com/postgres/postgres.git synced 2025-05-28 05:21:27 +03:00

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.
This commit is contained in:
Tom Lane 2007-07-20 16:30:05 +00:00
parent a0b2bb8ced
commit 6d8afdee00

View File

@ -11,7 +11,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/storage/smgr/smgr.c,v 1.93.2.4 2007/07/08 22:23:32 tgl Exp $
* $PostgreSQL: pgsql/src/backend/storage/smgr/smgr.c,v 1.93.2.5 2007/07/20 16:30:05 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -911,6 +911,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);
/* Can't use smgrtruncate because it would try to xlog */
/*