| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: pg_migrator issue with contrib |
| Date: | 2009-06-08 15:20:04 |
| Message-ID: | 22198.1244474404@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Let me list the problems with pg_migrator:
> o /contrib and plugin migration (not unique to pg_migrator)
> o you must read/follow the install instructions
> o might require post-migration table/index rebuilds
> o new so serious bugs might exist
I think that #1 and #4 could be substantially alleviated if the
instructions recommended doing a trial run with a schema-only dump
of the database. That is,
* pg_dumpall -s
* load that into a test installation (of the *old* PG version)
* migrate the test installation to new PG version
* do the same sorts of applications compatibility checks you'd want to
do anyway before a major version upgrade
This would certainly catch migration-time failures caused by plugins,
and the followup testing would probably catch any large post-migration
issue.
Somebody who is not willing to do this type of testing should not be
using pg_migrator (yet), and probably has not got a database large
enough to need it anyway.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2009-06-08 15:21:36 | Re: pg_migrator issue with contrib |
| Previous Message | Bruce Momjian | 2009-06-08 15:18:40 | Re: pg_migrator issue with contrib |