Re: pg_migrator issue with contrib

On Mon, Jun 8, 2009 at 1:20 PM, Bruce Momjian<bruce(at)momjian(dot)us> wrote:
> 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.

Fair enough. I'm game to use a different word. I spent approximately
30 seconds coming up with that suggestion. :-)

> For longterm strategy, let me list the challenges for pg_migrator from
> any major upgrade (listed in the DEVELOPERS file):
>
>  Change                                  Conversion Method
>  ------------------------------------------------------------------------------
>  clog                                    none
>  heap page header, including bitmask     convert to new page format on read
>  tuple header, including bitmask         convert to new page format on read
>  data value format                       create old data type in new cluster
>  index 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.

No arguments here, sounds like interesting stuff.

...Robert