Subject: Re: Release cycle length
References: <Pine.LNX.4.44.0311180038310.639-100000@peter.localdomain>
	<20031117202346.M731@ganymede.hub.org>
	<3FBB7F20.8050005@Yahoo.com> <6400.1069359578@sss.pgh.pa.us>
	<3FBD6CAA.7040500@familyhealth.com.au>
	<20031121130359.GE26392@dcc.uchile.cl>
	<3FBE5A46.4090102@Yahoo.com> <20031125050844.GC67015@nasby.net>
From: Christopher Browne <cbbrowne@acm.org>
Message-ID: <m3ekvxhu7q.fsf@wolfe.cbbrowne.com>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion,
	linux)
Cancel-Lock: sha1:TRmujRostU8TjRZXMsqFfgYcfFY=
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lines: 23
Date: Tue, 25 Nov 2003 00:51:05 -0500
Organization: Bell Sympatico
To: pgsql-hackers@postgresql.org

Quoth jim@nasby.net ("Jim C. Nasby"):
> On Fri, Nov 21, 2003 at 01:32:38PM -0500, Jan Wieck wrote:
>> bootstrap mode to apply the changes, could be an idea to think of. It 
>> would still require some downtime, but nobody can avoid that when 
>> replacing the postgres binaries anyway, so that's not a real issue. As 
>> long as it eliminates dump, initdb, reload it will be acceptable.
>  
> Has anyone looked at using replication as a migration method? If
> replication can be setup in such a way that you can replicate from an
> old version to a new version, you can use that to build the new version
> of the database on a seperate machine/instance while the old version is
> still live. With some sophisticated middleware, you could theoretically
> migrate without any downtime.

The idea has indeed been "looked at," and seems pretty feasible.

It would certainly take some sophisticated middleware to totally evade
downtime.  But replicating from "old version" to "new version" does
have the merit of keeping the downtime to fairly much a minimum.
-- 
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://www3.sympatico.ca/cbbrowne/x.html
:FATAL ERROR -- VECTOR OUT OF HILBERT SPACE