public inbox for [email protected]  

help / color / mirror / Atom feed

From: Heikki Linnakangas <[email protected]>
To: Simon Riggs <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: Aidan Van Dyk <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server  continuously retry restoring the next WAL
Date: Thu, 25 Mar 2010 12:05:37 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <1269505375.8481.8977.camel@ebony>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<1268988724.3556.3.camel@ebony>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<1269472981.8481.8946.camel@ebony>
	<[email protected]>
	<1269505375.8481.8977.camel@ebony>

Simon Riggs wrote:
> On Thu, 2010-03-25 at 11:08 +0900, Fujii Masao wrote:
>> And if the trigger file is
>> found, I think that the startup process should emit a FATAL, i.e., the
>> server should exit immediately, to prevent the server from becoming the
>> primary in a half-finished state. 
> 
> Please remember that "half-finished" is your judgment on what has
> happened in the particular scenario you are considering. In many cases,
> an invalid WAL record clearly and simply indicates the end of WAL and we
> should start up normally.

Not in the archive. An invalid WAL record in a file in pg_xlog is
usually an indication of end-of-WAL, but there should be no invalid
records in the archived WAL files, or streamed from the master.

> "State" is a good word here. I'd like to see the server have a clear
> state model with well documented transitions between them. The state
> should also be externally queriable, so we can work out what its doing
> and how long we can expect it to keep doing it for.

Agreed.

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

view thread (77+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Re: [COMMITTERS] pgsql: Make standby server  continuously retry restoring the next WAL
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox