Thread: pg_upgrade
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
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
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
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
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
>>>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
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
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
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
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