From: | "Thomas F(dot) O'Connell" <tf(at)o(dot)ptimized(dot)com> |
---|---|
To: | PgSQL-General <pgsql-general(at)postgresql(dot)org> |
Subject: | Interrupted pg_dump / pg_restore Upgrade |
Date: | 2007-01-05 00:18:40 |
Message-ID: | 953C1168-33E4-4236-B5D3-A2E0F83828F7@o.ptimized.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I just became involved in a scenario wherein a migration between
releases (8.1.x -> 8.2) using pg_dumpall piped to psql (per section
23.5 of the 8.2 docs) was interrupted based on duration of the
procedure. The interruption was green lit because it was determined
that the data had been migrated and that indexes and constraints were
still to come (indexes were actually mid-way). A decision was made to
go ahead and move forward with the 8.2 database with the intention of
rebuilding indexes and other constraints manually.
My big question is: Is there anything that happens late in the game
in a pg_dumpall that affects system catalogs or other non-data
internals in any critical ways that would make an interrupted
pg_dumpall | psql sequence unstable?
There are a number of irregularities turning up with the upgraded
database, and I'm trying to rule out as many root causes as possible.
The new database is 8.2 (as were all the client utilities used in the
migration), built from source, running on Solaris:
SunOS x41-xl-01.int 5.10 Generic_118855-19 i86pc i386 i86pc
--
Thomas F. O'Connell
optimizing modern web applications
: for search engines, for usability, and for performance :
http://o.ptimized.com/
615-260-0005
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-01-05 01:03:43 | Re: Interrupted pg_dump / pg_restore Upgrade |
Previous Message | Wes | 2007-01-04 22:23:45 | Re: Index vacuum improvements in 8.2 |