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

Don't try to truncate multixact SLRU files in checkpoints done during xlog

Browse Source 
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.
This commit is contained in:
Tom Lane 2006-07-20 00:46:42 +00:00
parent a8e44f0b1b
commit 9dc842f083
1 changed files with 8 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
src/backend/access/transam/multixact.c
View File

@ -42,7 +42,7 @@
* Portions Copyright (c) 1996-2006, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
* $PostgreSQL: pgsql/src/backend/access/transam/multixact.c,v 1.19 2006/07/13 16:49:13 momjian Exp $
* $PostgreSQL: pgsql/src/backend/access/transam/multixact.c,v 1.20 2006/07/20 00:46:42 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -1493,9 +1493,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();
}
/*