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 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. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
