Re: pg_migrator issue with contrib

Bruce Momjian wrote:
> > Oh, to me "experimental" does not imply that usefulness is uncertain;
> > rather, it implies that usefulness has been established but that the
> > code is new (item #4 above) and may be not be 100% feature-complete
> > (items #1 and #3 above).
> > 
> > > 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".
> > 
> > Precisely.  In other words, if you are an INEXPERIENCED user (that is
> > to say, most of them) or you don't have a particular large database,
> > dump + reload is probably the safest option.  We're not discouraging
> > you from use pg_migrator, but please be careful and observe that it is
> > new and has some limitations.
> 
> Agreed.  There is no reason for most users to need pg_migrator;  it is
> not worth the risk for them, however small.  There are some people who
> really need it, and hopefully they are experienced users, while there is
> a larger group who want to know such an option _exists_, so if they ever
> need it, it is available.

I think this "larger group" is where my problem with the word
"experimental" come in.  I think pg_migrator is far enough along that we
know it works, and that it will probably work for future major releases.
By calling it "experimental" we are not conveying confidence in the tool
for people who are making deployment decisions based on the existence of
such tool, even if they aren't going to use it initially.  And by not
conveying confidence, we will lose the adoption advantage we can get
from pg_migrator.

Now, we don't want to over-promise, but at the same time we shouldn't
downplay the tool either.  For a sufficiently-experienced administrator,
pg_migrator is a useful migration tool, and we need to convey that. 
Even if you have to hire a consultant to manage the migration, if it
saves days of downtime, it is worth it.  Consultants don't often use
experimental tools, but they do use complex, powerful tools that are
often rough around the edges in terms of usability, e.g. read the
INSTALL file carefully.

For longterm strategy, let me list the challenges for pg_migrator from
any major upgrade (listed in the DEVELOPERS file):
Change                                  Conversion
Method------------------------------------------------------------------------------clog
  noneheap page header, including bitmask     convert to new page format on readtuple header, including bitmask
convertto new page format on readdata value format                       create old data type in new clusterindex page
format                      reindex, or recreate old index methods
 

These are the issue we will have to address for 8.5 and beyond if
pg_migrator is to remain useful.

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