Skip site navigation (1) Skip section navigation (2)

Re: General migration question

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Greg Spiegelberg <gspiegelberg(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "[ADMIN]" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: General migration question
Date: 2010-08-31 15:42:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
On Tue, Aug 31, 2010 at 9:33 AM, Greg Spiegelberg
<gspiegelberg(at)gmail(dot)com> wrote:
> On Tue, Aug 31, 2010 at 9:07 AM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
>> Excerpts from Greg Spiegelberg's message of mar ago 31 09:04:18 -0400 2010:
>>> Probably questions best asked on hackers but I figure many are represented here.
>>> Will there ever be a release where a dump-restore is not necessary?
>>> Perhaps, at least, minor releases (e.g. 9.0 to 9.1) will not require a
>>> dump-restore?
>> 9.0 to 9.1 is not a minor release.  9.0.0 to 9.0.1 is a minor release,
>> and this doesn't require a dump/reload, but it also doesn't have any new
>> features.  9.0 to 9.1 is just as major as 8.4 to 9.0 is.  (The rule is:
>> a change in second digit is major release, a change in first digit is
>> marketing pressure)
> Okay, wrong terminology.  I meant minor release as in Major.Minor.Maintenance.

But you do understand that in pgsql, it's major.major.minor right?

> All I'm suggesting is lumping those things requiring a dump/restore
> together for major updates.

That's exactly what does happen, if you remember that pgsql is
numbered major.major.minor.

From 8.3 to 8.4, dump restore, 8.4 to 9.0 dump restore or pg_migrate,
and 9.0 to 9.1 will be the same.

Now if you meant to save them for 9.x to 10.x?  Not gonna happen.
That could be years.

In response to


pgsql-admin by date

Next:From: Bruce MomjianDate: 2010-08-31 15:44:50
Subject: Re: Tuple changes from relfilenodes
Previous:From: Greg SpiegelbergDate: 2010-08-31 15:33:56
Subject: Re: General migration question

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group