aboutsummaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2006-07-20 00:46:56 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2006-07-20 00:46:56 +0000
commitf1418801501f4d1d6394f7bb0fed3de219ab159b (patch)
tree70e934d08214805f802bd4ea52d5e8b4cdf1ade4 /src
parent74dac69e3c20487b0c2eacee05b4ff8ba12ce640 (diff)
downloadpostgresql-f1418801501f4d1d6394f7bb0fed3de219ab159b.tar.gz
postgresql-f1418801501f4d1d6394f7bb0fed3de219ab159b.zip
Don't try to truncate multixact SLRU files in checkpoints done during xlog
recovery. In the first place, it doesn't work because slru's latest_page_number isn't set up yet (this is why we've been hearing reports of strange "apparent wraparound" log messages during crash recovery, but only from people who'd managed to advance their next-mxact counters some considerable distance from 0). In the second place, it seems a bit unwise to be throwing away data during crash recovery anwyway. This latter consideration convinces me to just disable truncation during recovery, rather than computing latest_page_number and pushing ahead.
Diffstat (limited to 'src')
-rw-r--r--src/backend/access/transam/multixact.c11
1 files changed, 8 insertions, 3 deletions
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index f55f2c2c2fa..28750d24907 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -42,7 +42,7 @@
* Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
- * $PostgreSQL: pgsql/src/backend/access/transam/multixact.c,v 1.11.2.1 2005/11/22 18:23:05 momjian Exp $
+ * $PostgreSQL: pgsql/src/backend/access/transam/multixact.c,v 1.11.2.2 2006/07/20 00:46:56 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@@ -1490,9 +1490,14 @@ CheckPointMultiXact(void)
/*
* Truncate the SLRU files. This could be done at any time, but
- * checkpoint seems a reasonable place for it.
+ * checkpoint seems a reasonable place for it. There is one exception:
+ * if we are called during xlog recovery, then shared->latest_page_number
+ * isn't valid (because StartupMultiXact hasn't been called yet) and
+ * so SimpleLruTruncate would get confused. It seems best not to risk
+ * removing any data during recovery anyway, so don't truncate.
*/
- TruncateMultiXact();
+ if (!InRecovery)
+ TruncateMultiXact();
}
/*