public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jan Wieck <[email protected]>
To: Alvaro Herrera <[email protected]>
Cc: Christopher Kings-Lynne <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: PostgreSQL Development <[email protected]>
Subject: Re: Release cycle length
Date: Fri, 21 Nov 2003 13:32:38 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Alvaro Herrera wrote:

> On Fri, Nov 21, 2003 at 09:38:50AM +0800, Christopher Kings-Lynne wrote:
>> >Yeah, I think the main issue in all this is that for real production
>> >sites, upgrading Postgres across major releases is *painful*.  We have
>> >to find a solution to that before it makes sense to speed up the
>> >major-release cycle.
>> 
>> Well, I think one of the simplest is to do a topological sort of objects 
>>  in pg_dump (between object classes that need it), AND regression 
>> testing for pg_dump :)
> 
> One of the most complex would be to avoid the need of pg_dump for
> upgrades ...
> 

We don't need a simple way, we need a way to create some sort of catalog 
diff and "a safe" way to apply that to an existing installation during 
the upgrade.

I think with a shutdown postmaster, a standalone backend used to check 
that no conflicts exist in any DB, then using the new backend in 
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.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== [email protected] #

view thread (83+ 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], [email protected]
  Subject: Re: Release cycle length
  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