Re: Parameter name standby_mode

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parameter name standby_mode
Date: 2010-03-31 20:54:27
Message-ID: 4BB3B683.5080101@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-03-31 21:04:11 Re: Parameter name standby_mode
Previous Message Robert Haas 2010-03-31 20:45:32 Re: Alpha release this week?