Re: pg_migrator issue with contrib

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_migrator issue with contrib
Date: 2009-06-08 16:52:51
Message-ID: 603c8f070906080952k3652c1bfx9ba9c8ea86af6d6c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 8, 2009 at 11:08 AM, Bruce Momjian<bruce(at)momjian(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-06-08 16:55:45 Re: pg_migrator issue with contrib
Previous Message Tom Lane 2009-06-08 16:51:44 Re: pg_migrator issue with contrib