From: Dimitri Fontaine <dfontaine@hi-media.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	Fujii Masao <masao.fujii@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry
	restoring the next WAL
Organization: Hi-Media
References: <20100127152751.3B2047541B9@cvs.postgresql.org>
	<3f0b79eb1002092105r21e009d3v468496058ba04392@mail.gmail.com>
	<4B726120.80007@enterprisedb.com> <1265884657.7341.1192.camel@ebony>
	<4B73F678.8070109@enterprisedb.com> <1265891248.7341.1346.camel@ebony>
	<4B73FB99.4080403@enterprisedb.com> <1265893599.7341.1454.camel@ebony>
Date: Thu, 11 Feb 2010 14:41:15 +0100
In-Reply-To: <1265893599.7341.1454.camel@ebony> (Simon Riggs's message of
	"Thu, 11 Feb 2010 13:06:39 +0000")
Message-ID: <877hqjc2kk.fsf@hi-media-techno.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Simon Riggs <simon@2ndQuadrant.com> writes:
> If you were running pg_standby as the restore_command then this error
> wouldn't happen. So you need to explain why running pg_standby cannot
> solve your problem and why we must fix it by replicating code that has
> previously existed elsewhere.

Let me try.

pg_standby will not let the server get back to streaming replication
mode once it's done with driving the replay of all the WAL files
available in the archive, but will have the server sits there waiting
for the next file.

The way we want that is implemented now is to have the server switch
back and forth between replaying from the archive and streaming from the
master. So we want the server to restore from the archive the same way
pg_standby used to, except that if the archive does not contain the next
WAL files, we want to get back to streaming.

And the archive reading will resume at next network glitch.

I think it's the reasonning, I hope it explains what you see happening.
-- 
dim