On Sun, Jun 7, 2009 at 12:11 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> * intarray has removed its internal @> and <@ operators. As I was
> mentioning the other day, it might be the best thing to just revert
> that change anyway, until we can get a better handle on the behavior
> of GIN for empty arrays.
+1.
> So we've definitely got some work here. If we do nothing, several
> of these issues are going to end up with CVE numbers.
I think it's becoming increasingly clear that pg_migrator is not for
the faint of heart; in fact, I think we should hedge references to it
with words like "experimental". If we set an expectation that this
tool has the same level of maturity and reliability that people
associate with PostgreSQL in general, we are going to have a lot of
disappointed users. Just to recall the history, the first pgfoundry
commit messages for this tool were on February 9th, three months after
the start of the final CommitFest and feature freeze for 8.4. Since
then, development has proceeded at an amazingly rapid pace, but
there's only so much you can do in four months, especially when it's
too late to rearchitect previously-committed 8.4 features to play more
nicely with the new feature being added.
It seems to me that if we keep plugging at this problem, 8.4->8.5
migration has the potential to be considerably smoother than 8.3 to
8.4 migration (and, yes, a good module facility will help), but it
wouldn't be surprising to me if we're well into 9.x territory before
we really get all of the issues hammered out. I don't think even a
major feature like Hot Standby has the far-reaching implications on
how the system needs to be designed that upgrade-in-place does.
So while I agree with Tom that we should fix as many of these issues
as we reasonably well can for 8.4, I also agree with Bruce that a lot
of this comes down to setting appropriate expectations for our users:
this is a potentially useful tool, especially for users with huge
databases, but it's new, and it's not perfect, and use with caution.
...Robert