aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/init/postinit.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2010-04-20 01:38:52 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2010-04-20 01:38:52 +0000
commitc670410e7fe59dffb0227ed1dd0f532013993859 (patch)
treec647059112427738891c97e5e7ac0c53cce94782 /src/backend/utils/init/postinit.c
parentee7769bb7649e0f990179f9ed56e60c031542077 (diff)
downloadpostgresql-c670410e7fe59dffb0227ed1dd0f532013993859.tar.gz
postgresql-c670410e7fe59dffb0227ed1dd0f532013993859.zip
Move the responsibility for calling StartupXLOG into InitPostgres, for
those process types that go through InitPostgres; in particular, bootstrap and standalone-backend cases. This ensures that we have set up a PGPROC and done some other basic initialization steps (corresponding to the if (IsUnderPostmaster) block in AuxiliaryProcessMain) before we attempt to run WAL recovery in a standalone backend. As was discovered last September, this is necessary for some corner-case code paths during WAL recovery, particularly end-of-WAL cleanup. Moving the bootstrap case here too is not necessary for correctness, but it seems like a good idea since it reduces the number of distinct code paths.
Diffstat (limited to 'src/backend/utils/init/postinit.c')
-rw-r--r--src/backend/utils/init/postinit.c33
1 files changed, 24 insertions, 9 deletions
diff --git a/src/backend/utils/init/postinit.c b/src/backend/utils/init/postinit.c
index afd4bc65b27..5be80b8f689 100644
--- a/src/backend/utils/init/postinit.c
+++ b/src/backend/utils/init/postinit.c
@@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
- * $PostgreSQL: pgsql/src/backend/utils/init/postinit.c,v 1.208 2010/03/25 20:40:17 sriggs Exp $
+ * $PostgreSQL: pgsql/src/backend/utils/init/postinit.c,v 1.209 2010/04/20 01:38:52 tgl Exp $
*
*
*-------------------------------------------------------------------------
@@ -427,11 +427,9 @@ pg_split_opts(char **argv, int *argcp, char *optstr)
* Early initialization of a backend (either standalone or under postmaster).
* This happens even before InitPostgres.
*
- * If you're wondering why this is separate from InitPostgres at all:
- * the critical distinction is that this stuff has to happen before we can
- * run XLOG-related initialization, which is done before InitPostgres --- in
- * fact, for cases such as the background writer process, InitPostgres may
- * never be done at all.
+ * This is separate from InitPostgres because it is also called by auxiliary
+ * processes, such as the background writer process, which may not call
+ * InitPostgres at all.
*/
void
BaseInit(void)
@@ -512,11 +510,28 @@ InitPostgres(const char *in_dbname, Oid dboid, const char *username,
InitBufferPoolBackend();
/*
- * Initialize local process's access to XLOG, if appropriate. In
- * bootstrap case we skip this since StartupXLOG() was run instead.
+ * Initialize local process's access to XLOG.
*/
- if (!bootstrap)
+ if (IsUnderPostmaster)
+ {
+ /*
+ * The postmaster already started the XLOG machinery, but we need
+ * to call InitXLOGAccess(), if the system isn't in hot-standby mode.
+ * This is handled by calling RecoveryInProgress and ignoring the
+ * result.
+ */
(void) RecoveryInProgress();
+ }
+ else
+ {
+ /*
+ * We are either a bootstrap process or a standalone backend.
+ * Either way, start up the XLOG machinery, and register to have it
+ * closed down at exit.
+ */
+ StartupXLOG();
+ on_shmem_exit(ShutdownXLOG, 0);
+ }
/*
* Initialize the relation cache and the system catalog caches. Note that