Interrupted pg_dump / pg_restore Upgrade

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

Responses

Browse pgsql-general by date

  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