Re: Stefan's bug (was: max_standby_delay considered harmful) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Stefan's bug (was: max_standby_delay considered harmful)
Date
Msg-id 8578.1274710760@sss.pgh.pa.us
Whole thread Raw
In response to Re: Stefan's bug (was: max_standby_delay considered harmful)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, May 24, 2010 at 9:28 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On Mon, 2010-05-24 at 09:26 -0400, Robert Haas wrote:
>>> This looks pretty reasonable to me, but I guess I feel like it would
>>> be better to drive the CancelBackup() decision off of whether we've
>>> ever reached PM_RUN rather than consulting XLogCtl.
>> 
>> That is exactly what XLogCtl tells us and why it is suggested for use.

> Sure.  My only point is that the postmaster doesn't (and can't) use
> that method of getting the information at any other time when it is
> needed, so I don't know why we'd want to use it in just this one case.
>  Maybe there's a reason, but it's not obvious to me.

I'm with Robert on this.  The postmaster is designed to be driven by an
internal state machine.  Making it rely on the contents of shared memory
is a fundamentally dangerous idea.  It might coincidentally be safe in
this one case, but I can easily imagine that property failing as a result
of subsequent changes.

The postmaster should not look at shared memory if there is any
reasonable alternative, and we clearly have a reasonable alternative.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages
Next
From: "Greg Sabino Mullane"
Date:
Subject: Re: Specification for Trusted PLs?