Thread: pg_upgrade

pg_upgrade

From
Bruce Momjian
Date:
Tom asked about pg_upgrade as part of our initdb for timezone.

I have made some improvements to pg_upgrade in CVS and have successfully
migrated a regression database from a 7.2 to another 7.2 database using
it.  (At least the tables show some data;  very light testing.)

pg_upgrade is still disabled in CVS, it doesn't install, and there is no
manual page so it is still an unused command. I have made the commit so
people can review where I have gone and make comments.

To test it, you have to find the line that says 7.2 and remove the '#'
comment.  This is for testing purposes only, so far.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: pg_upgrade

From
Bruce Momjian
Date:
Bruce Momjian wrote:
> Tom asked about pg_upgrade as part of our initdb for timezone.
> 
> I have made some improvements to pg_upgrade in CVS and have successfully
> migrated a regression database from a 7.2 to another 7.2 database using
> it.  (At least the tables show some data;  very light testing.)
> 
> pg_upgrade is still disabled in CVS, it doesn't install, and there is no
> manual page so it is still an unused command. I have made the commit so
> people can review where I have gone and make comments.
> 
> To test it, you have to find the line that says 7.2 and remove the '#'
> comment.  This is for testing purposes only, so far.

Status report:  I have completed all the steps necessary for pg_upgrade
to work for 7.1->7.2 and for 7.2->7.2 databases.  I will run tests
tomorrow, and once I am sure it works, I will ask others to test.

I will not enable it until everyone agrees.  Are there people interested
in this tool being in 7.2, or who are against this tool being in 7.2?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: pg_upgrade

From
Joe Conway
Date:
Bruce Momjian wrote:

> 
> Status report:  I have completed all the steps necessary for pg_upgrade
> to work for 7.1->7.2 and for 7.2->7.2 databases.  I will run tests
> tomorrow, and once I am sure it works, I will ask others to test.
> 
> I will not enable it until everyone agrees.  Are there people interested
> in this tool being in 7.2, or who are against this tool being in 7.2?
> 


I have a good sized (~11 GB) database on 7.2b3. I'd like to try 
pg_upgrade to move it to CVS tip and/or 7.2RC1, so I guess I can be one 
of your testers.

-- Joe







Re: pg_upgrade

From
Peter Eisentraut
Date:
Bruce Momjian writes:

> I will not enable it until everyone agrees.  Are there people interested
> in this tool being in 7.2, or who are against this tool being in 7.2?

You're not going to like my opinion, but I'm going to put it forth anyway.
We've been working on this release for half a year, and there have been
far too many last-minute bright ideas that should have been postponed.
The fact that someone is going to want to upgrade their installation from
a previous release didn't just occur to us yesterday, so while this
development effort is commendable, this is just not the time.  I'm not
even going to list any technical reasons here, you can make up your own
list because you're looking at the code.  I'm just looking at the emails
and it gives me the creeps already.

-- 
Peter Eisentraut   peter_e@gmx.net



Re: pg_upgrade

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > I will not enable it until everyone agrees.  Are there people interested
> > in this tool being in 7.2, or who are against this tool being in 7.2?
> 
> You're not going to like my opinion, but I'm going to put it forth anyway.
> We've been working on this release for half a year, and there have been
> far too many last-minute bright ideas that should have been postponed.
> The fact that someone is going to want to upgrade their installation from
> a previous release didn't just occur to us yesterday, so while this
> development effort is commendable, this is just not the time.  I'm not
> even going to list any technical reasons here, you can make up your own
> list because you're looking at the code.  I'm just looking at the emails
> and it gives me the creeps already.

Gives me the creeps too.  :-)

I am working on it only because there isn't other stuff to do and it
isn't delaying anything because it is disabled anyway;  we can keep it
for 7.3 if we wish.  There was also the problem of a system catalog
change, and that got the fire moving.  Also, certain commerical
distributors bug me about this from time to time so even if we don't
officially use it my guess is that some of them may enable it anyway for
their distributions.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: pg_upgrade

From
Daniel Kalchev
Date:
>>>Bruce Momjian said:> I will not enable it until everyone agrees.  Are there people interested> in this tool being in
7.2,or who are against this tool being in 7.2?
 

I have never trusted pg_upgrade on production databases. This is where it is 
actually targeted to (to minimize downtime). I have always done full 
pg_dumpall and then full recreation of the database system, which 
unfortunately in my cases take few hours. With so many little changes in the 
structures pg_upgrade it is probably not very safe method anyway?

Just my opinion. :-)

Daniel



Re: pg_upgrade

From
Bruce Momjian
Date:
Daniel Kalchev wrote:
> >>>Bruce Momjian said:
>  > I will not enable it until everyone agrees.  Are there people interested
>  > in this tool being in 7.2, or who are against this tool being in 7.2?
> 
> I have never trusted pg_upgrade on production databases. This is where it is 
> actually targeted to (to minimize downtime). I have always done full 
> pg_dumpall and then full recreation of the database system, which 
> unfortunately in my cases take few hours. With so many little changes in the 
> structures pg_upgrade it is probably not very safe method anyway?
> 
> Just my opinion. :-)

I agree.  There are just too many people who complain to me about a lack
of pg_upgrade that I have to do my best on it and let people decide if
they want to use it.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: pg_upgrade

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> ...  I'm just looking at the emails
> and it gives me the creeps already.

FWIW, I would *never* trust a production database to pg_upgrade in its
current state; it's untested and can't possibly get enough testing
before release to be trustable.  But if Bruce wants to work on it,
where's the harm?  The discussions I've had with him over the past
couple days are more than valuable enough for development of a future
bulletproof pg_upgrade, whether or not the current script ever helps
anyone.

The only mistake we could make here is to advertise pg_upgrade as
reliable.  Which we will not do.
        regards, tom lane


Re: pg_upgrade

From
Bruce Momjian
Date:
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > ...  I'm just looking at the emails
> > and it gives me the creeps already.
> 
> FWIW, I would *never* trust a production database to pg_upgrade in its
> current state; it's untested and can't possibly get enough testing
> before release to be trustable.  But if Bruce wants to work on it,
> where's the harm?  The discussions I've had with him over the past
> couple days are more than valuable enough for development of a future
> bulletproof pg_upgrade, whether or not the current script ever helps
> anyone.
> 
> The only mistake we could make here is to advertise pg_upgrade as
> reliable.  Which we will not do.

Some people have large, non-critical databases they want to upgrade to
7.2.  I can imagine some people using pg_upgrade for those cases.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: pg_upgrade

From
Peter Eisentraut
Date:
Tom Lane writes:

> FWIW, I would *never* trust a production database to pg_upgrade in its
> current state; it's untested and can't possibly get enough testing
> before release to be trustable.  But if Bruce wants to work on it,
> where's the harm?

There isn't any harm working on it, but the question was whether we want
to enable it in the 7.2 release.  Given that you would "never" trust it in
its current state, and me just having seen the actual code, I think that
it's barely worth being put into contrib.  Where in fact it should
probably go.

> The only mistake we could make here is to advertise pg_upgrade as
> reliable.  Which we will not do.

Or ship pg_upgrade in a default installation and undermine the reliability
reputation for people who don't read advertisements.

-- 
Peter Eisentraut   peter_e@gmx.net