Skip site navigation (1) Skip section navigation (2)

Re: Standalone backends run StartupXLOG in an incorrect environment

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Standalone backends run StartupXLOG in an incorrect environment
Date: 2010-04-19 18:34:20
Message-ID: 3027.1271702060@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
I wrote:
> The point is that a standalone backend will fail to execute recovery
> correctly:
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg01297.php

After digging around a bit, it seems like the cleanest solution would be
to move the responsibility for calling StartupXLOG in a standalone
backend into InitPostgres.  At the point where the latter currently has

	/*
	 * Initialize local process's access to XLOG, if appropriate.  In
	 * bootstrap case we skip this since StartupXLOG() was run instead.
	 */
	if (!bootstrap)
		(void) RecoveryInProgress();

we'd add a couple of lines to call StartupXLOG if !IsUnderPostmaster,
and then remove the call from postgres.c.  I haven't tested this yet
but it looks like the correct state has been set up at that point.
Anyone see any obvious holes in the idea?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-04-19 19:10:49
Subject: Re: Thoughts on pg_hba.conf rejection
Previous:From: Simon RiggsDate: 2010-04-19 18:17:56
Subject: Re: Re: [COMMITTERS] pgsql: Tune GetSnapshotData() during Hot Standby by avoiding loop

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group