Re: Parameter name standby_mode - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Parameter name standby_mode
Date
Msg-id l2z603c8f071004050411n7b27ed30z74474b2c6493d529@mail.gmail.com
Whole thread Raw
In response to Re: Parameter name standby_mode  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Parameter name standby_mode  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
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.

...Robert


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: contrib check fail at pgcrypto on Windows Server 2008 64bit 9.0dev (HEAD near alpha5)
Next
From: Devrim GÜNDÜZ
Date:
Subject: Re: make check hangs in alpha5