Re: pg_migrator issue with contrib

Robert Haas wrote:
> > Right now nothing in the project is referring to pg_migrator except in
> > the press release, and it is marked as beta there. ?How do you want to
> > deemphasize it more than that? ?Why did I bother working on this if the
> > community reaction is to try to figure out how to make people avoid
> > using it?
> 
> Because Rome wasn't built in a day.
> 
> It seems to me that you yourself placed a far more disparaging label
> on it than anything that anyone has proposed today; this was a week
> ago:
> 
> http://archives.postgresql.org/pgsql-hackers/2009-05/msg01470.php
> 
> I don't think it's anyone's intention to disparage your work on this
> tool.  It certainly isn't mine.  But it seems obvious to me that it
> has some pretty severe limitations and warts.  The fact that those
> limitations and warts are well-documented doesn't negate their
> existence.  I also don't think calling the software "beta" or
> "experimental" is a way of deemphasizing it.  I think it's a way of
> being clear that this software is not the bullet-proof, rock-solid,
> handles-all-cases-and-keeps-on-trucking level of robustness that
> people have come to expect from PostgreSQL.
> 
> FWIW, I have no problem at all with mentioning pg_migrator in the
> release notes or the documentation; my failure to respond to your last
> emails on this topic was due to being busy and having already spent
> too much time responding to other emails, not due to thinking it was a
> bad idea.  I actually think it's a good idea.  But I also think those
> references should describe it as experimental, because I think it is.
> I really hope it won't remain experimental forever, but I think that's
> an accurate characterization of where it is now.

pg_migrator should be looked at critically here, and I agree we should
avoid letting pg_migrator failures reflect badly on Postgres.

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 instructionso  might
requirepost-migration table/index rebuildso  new so serious bugs might exist
 

and let me list its benefits:
o  first in-place upgrade capability in yearso  tested by some users, all successful (since late alpha)o  removes major
impedimentto adoptiono  includes extensive error checking and reportingo  contains detailed installation/usage
instructions

So let's look at pg_migrator as an opportunity and a risk.  As far as I
know, only Hiroshi Saito and I have have looked at the code.  Why don't
others read the pg_migrator source code looking for bugs?  Why have more
people not test it?

I think "experimental" is the wrong label.  Experimental assumes its
usefulness is uncertain and that it is still being researched ---
neither is true.  Once I release pg_migrator 8.4 final at the end of
this week (assuming no bugs are reported), I consider it done, or at
least advanced as far as I can go until I get more feedback from users.

I think we can say:  "pg_migrator is designed for experienced users with
large databases, for whom the typical dump/restore required for major
version upgrades is a hardship".

I assume this will be the same adoption pattern we had with the Win32
port, where it was a new platform in 8.0 and we dealt with some issues
as it was deployed, and that people who want it will find it and
hopefully it will be useful for them.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +