SEO

Hi to all,

We have a pretty big database that is going for an upgrade (PG7 -> PG8)
in the next few days, we have tested all the features of our application
but we cannot be sure that everything will work out perfectly (db is
managing several blob's only tables that have proven to be pretty hard
to configure).
I am currently investigating a worst-case-scenario strategy that would
be to downgrade the database from PG8 to 7 if anything goes wrong;00
this implies that we:
1) dump from a running PG8
2) remove PG8 and reinstall PG7
3) restore the dump into the running PG7

unfortunately pg_restore complains about the dump header and doesn't
restore the db at all, having tried to dump with both -Ft and -Fc flags

shall I try the "--ignore-version" option in pg_restore?
is there going to be any problem in using this option? (corrupted data,
tables, etc.)

Thanks, any help appreciated
Edoardo

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

> We have a pretty big database that is going for an upgrade (PG7 -> PG8)
> in the next few days, we have tested all the features of our application
> but we cannot be sure that everything will work out perfectly (db is
> managing several blob's only tables that have proven to be pretty hard
> to configure).
> I am currently investigating a worst-case-scenario strategy that would
> be to downgrade the database from PG8 to 7 if anything goes wrong;00
> this implies that we:
> 1) dump from a running PG8
> 2) remove PG8 and reinstall PG7
> 3) restore the dump into the running PG7
>
> unfortunately pg_restore complains about the dump header and doesn't
> restore the db at all, having tried to dump with both -Ft and -Fc flags
>
> shall I try the "--ignore-version" option in pg_restore?
> is there going to be any problem in using this option? (corrupted data,
> tables, etc.)

My understanding is that dumps are not backwards compatible. Any dumps created with a Version 8.*
pg_dump cannot be used for any older versions. If you want "play it safe" you should create a new
server for the postgresql version 8.1 to preform validation tests with your front-ends. After you
are satisfied that everything works well you can replace the version 7 production server with
version 8.

If you would like a safety net beyond this you could contact one of the PostgreSQL consulting
companies to walk you through the integration of V.8.1 into your projection system.

Regards,

Richard Broersma Jr.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

I wrote to Peter Wilson some day ago:
I had problems, like that. I've omitted them using "plain" format (SQL
script file) of dump file. I restore data from "plain" format with psql
- using command "\i FILE". It work always. If You gzip this "plain" file
- You become simillar volume of file using binary dump format.

....And in Your case (downgrade) You can do this way. When in the script
will be something incopatbile with PostgreSQL 7.3 - You can simply edit
the SQL script.
I've imported for expample in this way MySQL scripts made in MySQL into
PostgreSQL.

Greetings
Adam

Edoardo Ceccarelli wrote:
> Hi to all,
>
> We have a pretty big database that is going for an upgrade (PG7 -> PG8)
> in the next few days, we have tested all the features of our application
> but we cannot be sure that everything will work out perfectly (db is
> managing several blob's only tables that have proven to be pretty hard
> to configure).
> I am currently investigating a worst-case-scenario strategy that would
> be to downgrade the database from PG8 to 7 if anything goes wrong;00
> this implies that we:
> 1) dump from a running PG8
> 2) remove PG8 and reinstall PG7
> 3) restore the dump into the running PG7
>
> unfortunately pg_restore complains about the dump header and doesn't
> restore the db at all, having tried to dump with both -Ft and -Fc flags
>
> shall I try the "--ignore-version" option in pg_restore?
> is there going to be any problem in using this option? (corrupted data,
> tables, etc.)
>
> Thanks, any help appreciated
> Edoardo
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>

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

http://archives.postgresql.org

Thank you for this infos, I wasn't sure about this, now, at least, I know
that this is not possible.
On the other hand, even the most experienced database programmer /
administrator when upgrading a production environment can't be 100% sure
about whether the application,will fail or not.
Of course, testing is the only way to ensure that everything will be as
smooth as possible but a real safety net would be to establish a common dump
file format across different PG versions.
I will keep searching ... and testing of course


>
> My understanding is that dumps are not backwards compatible. Any dumps
> created with a Version 8.*
> pg_dump cannot be used for any older versions. If you want "play it safe"
> you should create a new
> server for the postgresql version 8.1 to preform validation tests with
> your front-ends. After you
> are satisfied that everything works well you can replace the version 7
> production server with
> version 8.
>
> If you would like a safety net beyond this you could contact one of the
> PostgreSQL consulting
> companies to walk you through the integration of V.8.1 into your
> projection system.
>
> Regards,
>
> Richard Broersma Jr.
>

Richard Broersma Jr wrote:

> My understanding is that dumps are not backwards compatible. Any dumps created with a Version 8.*
> pg_dump cannot be used for any older versions. If you want "play it safe" you should create a new
> server for the postgresql version 8.1 to preform validation tests with your front-ends. After you
> are satisfied that everything works well you can replace the version 7 production server with
> version 8.
>

I don't see that as being the case - there will be exceptions where you
have new features in an 8.x database that won't work in a 7.x db but
otherwise it shouldn't matter, the dumps can be used to import into
other databases than postgres as long as you use dump with inserts
instead of copy and use common datatypes.

I would expect that if you dump from 7.x into 8.x and have issues then a
dump from 8.x into 7.x would work as long as you haven't changed your
schema to add 8.x only features.

If you have any concerns and want a fall back safety net, then you will
want to either not add any 8.x features or document the changes so that
the structure can be changed back to be 7.x compatible.

Of course not making any schema changes until you are happy to stay with
8.x will help and you could just dump data only to go back.


--

Shane Ambler
pgSQL@007Marketing.com

Get Sheeky @ http://Sheeky.Biz

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Shane Ambler wrote:
> I don't see that as being the case - there will be exceptions where
> you have new features in an 8.x database that won't work in a 7.x db
> but otherwise it shouldn't matter, the dumps can be used to import
> into other databases than postgres as long as you use dump with
> inserts instead of copy and use common datatypes.

Restoring dumps from new versions into old versions doesn't work
(without a lot of manual work). Example cases:

8.2 dump won't install into 8.1 because it sets
standard_conforming_stings, which can't be set in 8.1

8.1 dump won't install into 8.0 because it dumps users as roles, but
roles don't exist in 8.0.

8.0 dump won't install into 7.4 because it dumps tablespaces, which
don't exist in 7.4.

etc. etc.

Obviously you can see that getting pretty bad if you want to go from 8.1
all the way to 7.3.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Nov 30, 2006, at 5:52 AM, Peter Eisentraut wrote:
> Shane Ambler wrote:
>> I don't see that as being the case - there will be exceptions where
>> you have new features in an 8.x database that won't work in a 7.x db
>> but otherwise it shouldn't matter, the dumps can be used to import
>> into other databases than postgres as long as you use dump with
>> inserts instead of copy and use common datatypes.
>
> Restoring dumps from new versions into old versions doesn't work
> (without a lot of manual work). Example cases:

On the other hand, dumping a newer version database with an older
version of *pg_dump* is much more likely to succeed. It's not a
guarantee, but it should get you pretty close. And as someone else
mentioned, doing a plain text dump is probably your best bet in this
case.
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

>
> On the other hand, dumping a newer version database with an older
> version of *pg_dump* is much more likely to succeed. It's not a
> guarantee, but it should get you pretty close. And as someone else
> mentioned, doing a plain text dump is probably your best bet in this case.

No, that's not an option, I have tried several combinations like using
old pg_dump on a new db but the results are always the same: no way to
restore a newer db on an older pg (my test were only about PG8 - PG7)
The best solution is the one that Adam was suggesting (btw Thank you) in
this same thread, doing a "pg_dump -Fp" on the new db and restoring it
with a
\i FILENAME from the old PG

The only issue about this is that it doesn't treat LO's at all, but it
was enough in my "disaster recovery" scenario.

I started investigating about dumping and restoring LO's and I found a
pretty interesting project under the 7.4 contrib dir, but it seems it's
not maintained any more and I didn't manage to compile it.
Using the lo_export - import function seems doesn't work for "ALL" the
LO's of the database.. maybe it's possible to write a query to do that
but - again - it wasn't so important to save blobs

Thank you again to everybody for your help
Edoardo


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Jim Nasby <decibel@decibel.org> writes:
> On the other hand, dumping a newer version database with an older
> version of *pg_dump* is much more likely to succeed.

You meant to say that the other way around, no? Certainly for a jump
this big I'd rather expect the older pg_dump to fail altogether.
[ experiments a bit... ] Both 7.3 and 7.4 pg_dump fail to talk to an
8.1 server; they expect pg_database.datpath to exist. 8.0 pg_dump
seems to do OK with 8.1 ... has some problems with 8.2 though.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match