pg_migrator to /contrib in a later 9.0 beta
in [PgSql]
|
Prev: [HACKERS] pg_migrator to /contrib in a later 9.0 beta
Next: [HACKERS] failed assertion and panic in standby mode
From: Bruce Momjian on 1 May 2010 17:42 Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: > > On Sat, May 1, 2010 at 11:42 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > >> I think that having it in contrib for a release cycle or so would be > >> exactly the right approach, actually. �Peter's position that it should > >> be in /bin is fine *once the bugs are out*. �Just dropping it there > >> doesn't make the bugs go away. > > > I think in the previous iteration of this discussion I had the > > impression that you felt that it wasn't really to the point where it > > even met our standards for /contrib (although, admittedly, it seems > > those are pretty darn low, at least as far as the stuff that's already > > in there goes). If I misunderstood or if that that's no longer your > > feeling then maybe it makes sense. > > In the 8.3->8.4 cycle I did think it was pretty half-baked. We've > stomped many of the worst limitations since then, so I think that for > 8.4->9.0 it might be a credible solution. We won't really know unless > we try. True. I do see this as a much-requested feature (like built-in replication). > > But I don't think we should do it > > at this point unless it's as simple as "check it in and ship it". If > > doing this seems likely to make 9.0 take longer to get out the door, > > then I think we should wait and do it in 9.1 instead. > > Agreed, we're not holding up 9.0 for it. I think the main bit of work > that would be needed to put it into contrib would be to SGML-ize the > docs. Don't know if Bruce has got the time to get that done. Creating the SGML docs is trivial, especially compared to the 9.0 release notes SGML. ;-) It will take only an hour --- I am basically going to merge the README and the INSTALL file, remove mentions about migrating to < 9.0, and add SGML markup. I labored on README and the INSTALL files for a long time and can't figure out how to improve them. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 1 May 2010 17:46 > > Agreed, we're not holding up 9.0 for it. I think the main bit of work > > that would be needed to put it into contrib would be to SGML-ize the > > docs. Don't know if Bruce has got the time to get that done. > > Creating the SGML docs is trivial, especially compared to the 9.0 > release notes SGML. ;-) It will take only an hour --- I am basically > going to merge the README and the INSTALL file, remove mentions about > migrating to < 9.0, and add SGML markup. I labored on README and the > INSTALL files for a long time and can't figure out how to improve them. Oh, and I will remove the C code that was used to migrate _to_ pre-9.0 databases. People can use the pgfoundry version for such cases. I have specifically not created a pgfoundry release of pg_migrator that migrates to 9.0. (It worked for the 8.5 numbering.) -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: =?ISO-8859-1?Q?C=E9dric_Villemain?= on 1 May 2010 19:55 2010/5/1 Bruce Momjian <bruce(a)momjian.us>: > Tom Lane wrote: >> Bruce Momjian <bruce(a)momjian.us> writes: >> > While most of the limitations in previous versions of pg_migrator are >> > gone, there are still issues with migrating /contrib modules, and there >> > are many steps to its use. >> >> > I think to attain mass usage of pg_migrator, some type of one-click >> > installer has to be built that can access the operating system and make >> > the migration process simple, though that is probably beyond what we as >> > a community are going to do. >> >> While the above are true statements, IMO the real gating factor right now >> for pg_migrator is that people don't know whether they can trust it. >> It won't get over that basic hump without a lot more real-world testing; >> and as long as it's a separately distributed project I don't think it'll >> get the necessary level of testing. That's why I feel it needs some > > Agreed. > >> time in contrib --- and why I don't have a warm fuzzy feeling about >> Peter's proposal to push it directly into the core project. > > I am unclear why it would be in /bin if it requires 15 steps to run and > is run only once by only some users. It seems natural for /contrib, > like pgcrypto. Do we already have a process to upgrade postgres + HotStandby (9.0->9.1 for example) ? > >> As for the "one click" aspect, I think that that's largely on the heads >> of packagers to provide some convenient method of using it. For the RPM >> packages, I envision eventually having a "postgresql-migrate" package >> that contains pg_migrator, a copy of the version-N-minus-1 postmaster, >> and some sort of frontend script. Install, run the script, remove. >> But we're a long way from that yet. > > Yes, that is what is needed eventually. > > -- > Bruce Momjian <bruce(a)momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Cédric Villemain -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 1 May 2010 21:02 C�dric Villemain wrote: > 2010/5/1 Bruce Momjian <bruce(a)momjian.us>: > > Tom Lane wrote: > >> Bruce Momjian <bruce(a)momjian.us> writes: > >> > While most of the limitations in previous versions of pg_migrator are > >> > gone, there are still issues with migrating /contrib modules, and there > >> > are many steps to its use. > >> > >> > I think to attain mass usage of pg_migrator, some type of one-click > >> > installer has to be built that can access the operating system and make > >> > the migration process simple, though that is probably beyond what we as > >> > a community are going to do. > >> > >> While the above are true statements, IMO the real gating factor right now > >> for pg_migrator is that people don't know whether they can trust it. > >> It won't get over that basic hump without a lot more real-world testing; > >> and as long as it's a separately distributed project I don't think it'll > >> get the necessary level of testing. ?That's why I feel it needs some > > > > Agreed. > > > >> time in contrib --- and why I don't have a warm fuzzy feeling about > >> Peter's proposal to push it directly into the core project. > > > > I am unclear why it would be in /bin if it requires 15 steps to run and > > is run only once by only some users. ?It seems natural for /contrib, > > like pgcrypto. > > Do we already have a process to upgrade postgres + HotStandby > (9.0->9.1 for example) ? No because when you create the file system backup and restore it to the new server, it is still running the same Postgres major version. There is no facility to handle major-version-changed master/slave setups. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 1 May 2010 23:23
On Sat, May 1, 2010 at 5:46 PM, Bruce Momjian <bruce(a)momjian.us> wrote: >> > Agreed, we're not holding up 9.0 for it. I think the main bit of work >> > that would be needed to put it into contrib would be to SGML-ize the >> > docs. Don't know if Bruce has got the time to get that done. >> >> Creating the SGML docs is trivial, especially compared to the 9.0 >> release notes SGML. ;-) It will take only an hour --- I am basically >> going to merge the README and the INSTALL file, remove mentions about >> migrating to < 9.0, and add SGML markup. I labored on README and the >> INSTALL files for a long time and can't figure out how to improve them. > > Oh, and I will remove the C code that was used to migrate _to_ pre-9.0 > databases. People can use the pgfoundry version for such cases. I have > specifically not created a pgfoundry release of pg_migrator that > migrates to 9.0. (It worked for the 8.5 numbering.) I wonder if this is just going to lead to us maintaining two versions of pg_migrator, which wouldn't be awesome. I don't think it's going to be practical to retain all the migration code for every pair of versions forever, but I'm reluctant to start changing things just because we're sucking the thing into our main tree. Especially things that sound suspiciously like features. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |