Re: Standalone backends run StartupXLOG in an incorrect environment - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Standalone backends run StartupXLOG in an incorrect environment
Date
Msg-id 14536.1271690360@sss.pgh.pa.us
Whole thread Raw
In response to Re: Standalone backends run StartupXLOG in an incorrect environment  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Standalone backends run StartupXLOG in an incorrect environment  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Standalone backends run StartupXLOG in an incorrect environment  (Robert Haas <robertmhaas@gmail.com>)
Re: Standalone backends run StartupXLOG in an incorrect environment  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Mar 22, 2010 at 9:32 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> OK, �I re-read it and still don't understand, but I don't have to.

> I re-read it too and I don't understand either.

The point is that a standalone backend will fail to execute recovery
correctly:
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01297.php
This is bad enough now but seems likely to be an even bigger foot-gun
in an HS/SR world.

> This is LISTED as an
> open item for 9.0, but it is apparently not a new regression, so I
> think we should move it to the Todo list instead.  This problem was
> discovered six months ago, is not a new regression, and there is
> apparently no movement toward a fix, so it doesn't make sense to me
> that we should hold up either 9.0 beta or 9.0 final on account of it.

If you think we're at the point where this item is the main thing
standing between us and beta, I'll go do something about it.  I've
been waiting for the HS code to settle before trying to design a
solution...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Re: [BUGS] BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation
Next
From: Andrew Dunstan
Date:
Subject: Re: perltidy