Re: Parameter name standby_mode - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Parameter name standby_mode
Date
Msg-id 1270467270.24910.3278.camel@ebony
Whole thread Raw
In response to Re: Parameter name standby_mode  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parameter name standby_mode
List pgsql-hackers
On Mon, 2010-04-05 at 07:11 -0400, Robert Haas wrote:
> On Mon, Apr 5, 2010 at 4:46 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> > On Wed, 2010-03-31 at 23:54 +0300, Heikki Linnakangas wrote:
> >> Robert Haas wrote:
> >> > Agreed.  I think if the server starts up in standby mode and it is an
> >> > inconsistent state with no source of WAL, then the startup process
> >> > should exit with a suitable error message, which AIUI will result in
> >> > the whole server shutting down.  However if there is no source of WAL
> >> > but the server is in a consistent state, then I think we should allow
> >> > it to start up as a read-only standby.
> >> >
> >> > Now, an interesting question is - if the server is in this state, and
> >> > somebody manually drops more WAL into pg_xlog, what happens? And what
> >> > happens in the similar case where primary_conninfo is set but we can't
> >> > connect to the master at the moment, and someone drops a pile of WAL
> >> > on us?
> >>
> >> With the recent changes to the retry logic
> >> (http://archives.postgresql.org/pgsql-committers/2010-03/msg00356.php),
> >> they will be replayed. Even if neither primary_conninfo or
> >> restore_command is given, the server will still keep polling pg_xlog,
> >> and if you copy a WAL file to standby's pg_xlog directory, it will be
> >> replayed and recovery will make progress.
> >>
> >> I wouldn't recommend setting up a standby server like that, but it's not
> >> totally unreasonable. So the standby always has a potential source of
> >> WAL, pg_xlog.
> >
> > I have inadvertently made it impossible to specify
> >   standby_mode && (!primary_conninfo && !restore_command)
> >
> > I did that because Robert had separately to this thread reported a hang,
> > caused by this specification. I have verified this.
> 
> I don't remember reporting this (or maybe you meant the other Robert);
> but there are so many threads on this topic that it's hard to keep
> track of them all.  Can you refresh my memory?
> 
> > pg_xlog is a *potential* source of WAL, but if the files requested are
> > not present then the server just sits and waits with *no* messages. That
> > is unacceptable, IMHO.
> >
> > What should we do now?
> 
> Well, actually, what it does for me is sits there and prints the last
> xlog location over and over again every 2s.  I'd actually like to get
> to "sits and waits with no messages", but it's not clear how to do
> that.

That's exactly the opposite of your report. Thread you started, on
hackers, in last week or so.

It's not clear to me *why* you would want it to sit there doing nothing,
and even if that has a purpose, saying nothing at all is not useful.
(Note that it cannot enter Hot Standby mode even in that state).

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Devrim GÜNDÜZ
Date:
Subject: Re: make check hangs in alpha5
Next
From: Robert Haas
Date:
Subject: Re: Parameter name standby_mode