Re: pg_migrator issue with contrib - Mailing list pgsql-hackers

On Mon, Jun 8, 2009 at 11:08 AM, Bruce Momjian<bruce@momjian.us> wrote:
> 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 instructions
>        o  might require post-migration table/index rebuilds
>        o  new so serious bugs might exist

I pretty much agree with this list.  With respect to #2, I don't think
that it's asking a lot for people to read/follow the install
instructions, so I don't consider that a serious problem.

> and let me list its benefits:
>
>        o  first in-place upgrade capability in years
>        o  tested by some users, all successful (since late alpha)
>        o  removes major impediment to adoption
>        o  includes extensive error checking and reporting
>        o  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?

No reason at all - I very much hope that happens.

> 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.

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.

> 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.

Completely agree.  And like the Windows port, hopefully after a
release or two, we'll figure out what we can improve and do so.  I am
interested in this problem but all of my free time lately has been
going into the EXPLAIN patch I'm working on, so I haven't had time to
dig into it much.  The problems of being a hobbyist...

...Robert