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 : |
