Thread: 7.2.3-7.4.2 migration
Hello,
First let me introduce myself as i'm posting for the first time.
I'm a project manager working for a french e-crm company, that is dealing with packaged email managing solutions, both inbound and outbound.
Our technical solutions relies on perl, c++, corba, apache and Postgres 7.2.3.
We were waiting for 7.4.2 to upgrade. As it is out now, i have some questions to ask.
The point is that we must upgrade our clients database, with loads of data in.
First, is it possible to upgrade directly from 7.2.3 --> 7.4.2 : ie dump the 7.2.3 datas, upgrade to 7.4.2, then restore the 7.2.3 datas?
or shall we do 7.3 upgrade, restore datas, dump, then 7.4 db upgrade, restore datas?
I would then appreciate if anyone can report a similar experience, problems faced and so on..
Thanks a lot by advance
Christophe Musielak
First let me introduce myself as i'm posting for the first time.
I'm a project manager working for a french e-crm company, that is dealing with packaged email managing solutions, both inbound and outbound.
Our technical solutions relies on perl, c++, corba, apache and Postgres 7.2.3.
We were waiting for 7.4.2 to upgrade. As it is out now, i have some questions to ask.
The point is that we must upgrade our clients database, with loads of data in.
First, is it possible to upgrade directly from 7.2.3 --> 7.4.2 : ie dump the 7.2.3 datas, upgrade to 7.4.2, then restore the 7.2.3 datas?
or shall we do 7.3 upgrade, restore datas, dump, then 7.4 db upgrade, restore datas?
I would then appreciate if anyone can report a similar experience, problems faced and so on..
Thanks a lot by advance
Christophe Musielak
On Thursday 01 April 2004 12:12, Christophe Musielak wrote: > > I'm a project manager working for a french e-crm company, that is > dealing with packaged email managing solutions, both inbound and > outbound. Hello Cristophe > First, is it possible to upgrade directly from 7.2.3 --> 7.4.2 : ie dump > the 7.2.3 datas, upgrade to 7.4.2, then restore the 7.2.3 datas? > or shall we do 7.3 upgrade, restore datas, dump, then 7.4 db upgrade, > restore datas? I don't think you'd gain anything by doing the upgrade in two steps. The main thing you'll notice is the introduction of schemas. Check for the use of 'now' as a default value too. Probably worth spending an hour or two reviewing the release notes in the manual to look for changes. > I would then appreciate if anyone can report a similar experience, > problems faced and so on.. I tend to do a schema-only followed by a data-only restore. The main problems I have are to do with dependencies between objects (function F relies on table T existing). I use the -l/-L flags on pg_restore to let me manually reorder the few items with problems. Once the schema is transferred, I restore the data using the --use-set-session-authorization and --disable-triggers flags. Where possible, I try to script any changes I have to make - especially worthwhile in your case I'd have thought. HTH -- Richard Huxton Archonet Ltd
On Thu, Apr 01, 2004 at 01:01:21PM +0100, Richard Huxton wrote: > On Thursday 01 April 2004 12:12, Christophe Musielak wrote: > > I would then appreciate if anyone can report a similar experience, > > problems faced and so on.. > > I tend to do a schema-only followed by a data-only restore. The main problems > I have are to do with dependencies between objects (function F relies on > table T existing). I use the -l/-L flags on pg_restore to let me manually > reorder the few items with problems. CVS tip's pg_dump orders objects more appropiately than before - AFAIU the dump is always correct. If you have this kind of problem, the new code could save you some work. If you use it, make sure you use the "-X disable-dollar-quoting" switch too, because otherwise the dump won't be loadable on released versions. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell." (L. Torvalds)
Richard Huxton <dev@archonet.com> writes: > On Thursday 01 April 2004 12:12, Christophe Musielak wrote: >> First, is it possible to upgrade directly from 7.2.3 --> 7.4.2 : ie dump >> the 7.2.3 datas, upgrade to 7.4.2, then restore the 7.2.3 datas? >> or shall we do 7.3 upgrade, restore datas, dump, then 7.4 db upgrade, >> restore datas? > I don't think you'd gain anything by doing the upgrade in two steps. I agree; that just doubles the work. One note: you'd be well advised to execute the dump using 7.4's pg_dump rather than 7.2's. Later pg_dumps often fix problems in earlier ones. > I tend to do a schema-only followed by a data-only restore. That will slow things down a bit because indexes and foreign keys will be built/checked incrementally rather than in one go. What I definitely *would* recommend is trying a schema-only dump first to check for problems. If that loads, drop it again and go for a full dump. If not, you can work out a solution without pushing so much data around ... regards, tom lane
Thanks for your advices.
Christophe
Le jeu 01/04/2004 à 17:28, Tom Lane a écrit :
Christophe
Le jeu 01/04/2004 à 17:28, Tom Lane a écrit :
Richard Huxton <dev@archonet.com> writes: > On Thursday 01 April 2004 12:12, Christophe Musielak wrote: >> First, is it possible to upgrade directly from 7.2.3 --> 7.4.2 : ie dump >> the 7.2.3 datas, upgrade to 7.4.2, then restore the 7.2.3 datas? >> or shall we do 7.3 upgrade, restore datas, dump, then 7.4 db upgrade, >> restore datas? > I don't think you'd gain anything by doing the upgrade in two steps. I agree; that just doubles the work. One note: you'd be well advised to execute the dump using 7.4's pg_dump rather than 7.2's. Later pg_dumps often fix problems in earlier ones. > I tend to do a schema-only followed by a data-only restore. That will slow things down a bit because indexes and foreign keys will be built/checked incrementally rather than in one go. What I definitely *would* recommend is trying a schema-only dump first to check for problems. If that loads, drop it again and go for a full dump. If not, you can work out a solution without pushing so much data around ... regards, tom lane