X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (neptune.hub.org [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 60D7DD1B578 for ; Fri, 21 Nov 2003 18:34:06 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 62833-09 for ; Fri, 21 Nov 2003 14:33:36 -0400 (AST) Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by svr1.postgresql.org (Postfix) with SMTP id DE50AD1B553 for ; Fri, 21 Nov 2003 14:33:34 -0400 (AST) Received: from pcp01341166pcs.wilog301.pa.comcast.net (HELO europa.janwieck.net) (janwieck@68.80.245.191 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 21 Nov 2003 18:33:34 -0000 Received: from Yahoo.com (ismtp.afilias.com [216.217.55.254]) (authenticated) by europa.janwieck.net (8.11.6/8.11.6) with ESMTP id hALIXLo32316; Fri, 21 Nov 2003 13:33:21 -0500 Message-ID: <3FBE5A46.4090102@Yahoo.com> Date: Fri, 21 Nov 2003 13:32:38 -0500 From: Jan Wieck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alvaro Herrera Cc: Christopher Kings-Lynne , Tom Lane , Peter Eisentraut , PostgreSQL Development Subject: Re: Release cycle length References: <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> In-Reply-To: <20031121130359.GE26392@dcc.uchile.cl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200311/1196 X-Sequence-Number: 47484 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. # #================================================== JanWieck@Yahoo.com #