Re: pg_migrator issue with contrib - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: pg_migrator issue with contrib |
Date | |
Msg-id | 603c8f070906081025p1854e091x7805fc987ec50f6c@mail.gmail.com Whole thread Raw |
In response to | Re: pg_migrator issue with contrib (Bruce Momjian <bruce@momjian.us>) |
Responses |
Re: pg_migrator issue with contrib
(Bruce Momjian <bruce@momjian.us>)
|
List | pgsql-hackers |
On Mon, Jun 8, 2009 at 1:20 PM, Bruce Momjian<bruce@momjian.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
pgsql-hackers by date: