By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,386 Members | 1,156 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,386 IT Pros & Developers. It's quick & easy.

7.2.3-7.4.2 migration

P: n/a
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

Nov 23 '05 #1
Share this Question
Share on Google+
4 Replies

P: n/a
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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 23 '05 #2

P: n/a
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)

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 23 '05 #3

P: n/a
Richard Huxton <de*@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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 23 '05 #4

P: n/a
Thanks for your advices.

Christophe

Le jeu 01/04/2004 à 17:28, Tom Lane a écrit :
Richard Huxton <de*@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


Nov 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.