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

• Re: Standalone backends run StartupXLOG in an incorrect environment at 2010-04-19 15:19:20 from Tom Lane

Responses

• Re: Standalone backends run StartupXLOG in an incorrect environment at 2010-04-19 19:14:44 from Simon Riggs

pgsql-hackers by date

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