C�dric Villemain wrote:
> 2010/5/1 Bruce Momjian <bruce@momjian.us>:
> > Tom Lane wrote:
> >> Bruce Momjian <bruce@momjian.us> writes:
> >> > While most of the limitations in previous versions of pg_migrator are
> >> > gone, there are still issues with migrating /contrib modules, and there
> >> > are many steps to its use.
> >>
> >> > I think to attain mass usage of pg_migrator, some type of one-click
> >> > installer has to be built that can access the operating system and make
> >> > the migration process simple, though that is probably beyond what we as
> >> > a community are going to do.
> >>
> >> While the above are true statements, IMO the real gating factor right now
> >> for pg_migrator is that people don't know whether they can trust it.
> >> It won't get over that basic hump without a lot more real-world testing;
> >> and as long as it's a separately distributed project I don't think it'll
> >> get the necessary level of testing. ?That's why I feel it needs some
> >
> > Agreed.
> >
> >> time in contrib --- and why I don't have a warm fuzzy feeling about
> >> Peter's proposal to push it directly into the core project.
> >
> > I am unclear why it would be in /bin if it requires 15 steps to run and
> > is run only once by only some users. ?It seems natural for /contrib,
> > like pgcrypto.
>
> Do we already have a process to upgrade postgres + HotStandby
> (9.0->9.1 for example) ?
No because when you create the file system backup and restore it to the
new server, it is still running the same Postgres major version. There
is no facility to handle major-version-changed master/slave setups.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com