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 16:32 Robert Haas wrote: > On Sat, May 1, 2010 at 11:42 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas(a)gmail.com> writes: > >> On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander <magnus(a)hagander.net> wrote: > >>> A lot of people are not willing to put stuff labeled "contrib" on > >>> their production boxes. > >>> > >>> And as Tom says, even we *ourselves* acknowledge that things in > >>> /contrib are held to a lower standard. If we put that label on > >>> pg_migrator, it doesn't exactly signal people that this is something > >>> they should use on their critical database. > > > >> Well, I guess that begs the question... ?IS this something they should > >> use on their critical database? > > > > Not unless it gets some serious testing during the 9.0 beta cycle. > > Which it surely won't get if it's not included in the core tarball. > > > > 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. But I don't think we should do it Well, the original suggestion to move pg_migrator to /contrib was that it would be easier to do per-major-version distributions of pg_migrator. However, I have code that is pretty clear about what version it is dealing with, so I am not worried about that. One concern I had that it would be harder to make fixes to pg_migrator if it was tied to Postgres releases. However, I am no longer worried about that because I have not made changes to pg_migrator for months. (Six months ago I was making major changes to pg_migrator regularly.) > 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. I can't imagine why pg_migrator would ever delay 9.0 -- it is in /contrib and everything it needs is already in the backend code. We could always rip it back out of /contrib if we wanted to, or disable it. That's the beauty of /contrib --- it is isolated from the rest of the system. I think the big question is whether we want to provide a binary upgrade facility for Postgres. If so, pg_migrator is the only facility currently available, and I can't imagine another option appearing. I would love for pg_migrator to be easier to use, but I can't figure out how that can happen without an external OS-specific installer. -- 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 16:37 > I think the big question is whether we want to provide a binary upgrade > facility for Postgres. If so, pg_migrator is the only facility > currently available, and I can't imagine another option appearing. I > would love for pg_migrator to be easier to use, but I can't figure out > how that can happen without an external OS-specific installer. FYI, the length of this thread is kind of why I waited for beta to talk about pg_migrator. pg_migrator is really external to the backend code and now we have the leisure time to talk about it, understand what /contrib is useful for, and make a decision. -- 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: Tom Lane on 1 May 2010 16:37 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 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. 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. regards, tom lane -- 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: Tom Lane on 1 May 2010 16:43 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. > 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. regards, tom lane -- 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:26
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. > 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 |