Prev: Hot Standby tuning for btree_xlog_vacuum()
Next: pg_migrator to /contrib in a later 9.0 beta
From: Bruce Momjian on 29 Apr 2010 17:34
Tom Lane wrote:
> Robert Haas <robertmhaas(a)gmail.com> writes:
> > On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian <bruce(a)momjian.us> wrote:
> >> There was talk of including pg_migrator in Postgres 9.0 in /contrib. �Do
> >> we still want to do that?
>
> > I think you articulated some pretty good reasons previously for
> > keeping it separate and, at any rate, I'm not eager to do it at the
> > 11th hour without due consideration and adequate engineering time.
>
> I concur; it's about a month too late to propose this.

I talked to a few people personally about this, and it seems there was a
misunderstanding. I was not asking if pg_migrator should be in 9.0
beta1. I was asking if we should think about putting it into a later
9.0 beta, like 9.0 beta3. It would be another major 9.0 feature.

Because pg_migrator is an external project, it seemed best to do it
after beta1, while we are just waiting for bug reports, and not during
our main push to beta1.

FYI, here was the last discussion about having pg_migrator in /contrib
in December 2009:

http://archives.postgresql.org/pgsql-hackers/2009-12/msg01787.php

and most of the limitations of pg_migrator are gone when migrating to
9.0, even from Postgres 8.3. This could help beta testers move their
data to 9.0 as well.

--
Bruce Momjian <bruce(a)momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: Hot Standby tuning for btree_xlog_vacuum()
Next: pg_migrator to /contrib in a later 9.0 beta