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: