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: Magnus Hagander on 1 May 2010 03:32 On Sat, May 1, 2010 at 02:23, Bruce Momjian <bruce(a)momjian.us> wrote: > Tom Lane wrote: >> Dimitri Fontaine <dfontaine(a)hi-media.com> writes: >> > Peter Eisentraut <peter_e(a)gmx.net> writes: >> >> I also think that the standards for contrib should not be so lax that a >> >> completely new module can be added after beta. (This is mostly informed >> >> by the feeling that contrib should go away entirely.) >> >> > +1 >> >> > For the record, the contrib replacement would look like proper Extension >> > handling in dump&restore, PGXS support for windows, and PGAN for source >> > level archive distribution. We'd still rely on distributions support for >> > binaries. >> >> Both of you are living in some fantasy land. The reason contrib is held >> to a lower standard than core is that nobody is willing to put the same >> level of effort into contrib. There are modules in there (most of them, >> in fact) that haven't been touched for years, other than as part of >> system-wide search-and-replace patches. Extension support is not going >> to magically fix that and cause maintenance effort to appear from >> nowhere. >> >> In the end, the main useful function that contrib serves is to provide >> examples of how to write Postgres extensions. Because of that, removing >> it as Peter suggests doesn't seem like a good idea to me. > > So what do people want to do with pg_migrator? I don't think calling > pg_migrator a major features requires it to be in /bin. We added full > text search to /contrib years ago and that was a major feature. There is a reason people said that "8.3 comes with full text search" - that's when it really became a major feature to the outside world. Before that, it wasn't included in most comparisons. It was a PITA to install (well, not install, but upgrading when you had it, etc). (once you knew the insides, it was a major feature yes, but people didn't know about that) 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. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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 06:49 On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander <magnus(a)hagander.net> wrote: > On Sat, May 1, 2010 at 02:23, Bruce Momjian <bruce(a)momjian.us> wrote: >> Tom Lane wrote: >>> Dimitri Fontaine <dfontaine(a)hi-media.com> writes: >>> > Peter Eisentraut <peter_e(a)gmx.net> writes: >>> >> I also think that the standards for contrib should not be so lax that a >>> >> completely new module can be added after beta. (This is mostly informed >>> >> by the feeling that contrib should go away entirely.) >>> >>> > +1 >>> >>> > For the record, the contrib replacement would look like proper Extension >>> > handling in dump&restore, PGXS support for windows, and PGAN for source >>> > level archive distribution. We'd still rely on distributions support for >>> > binaries. >>> >>> Both of you are living in some fantasy land. The reason contrib is held >>> to a lower standard than core is that nobody is willing to put the same >>> level of effort into contrib. There are modules in there (most of them, >>> in fact) that haven't been touched for years, other than as part of >>> system-wide search-and-replace patches. Extension support is not going >>> to magically fix that and cause maintenance effort to appear from >>> nowhere. >>> >>> In the end, the main useful function that contrib serves is to provide >>> examples of how to write Postgres extensions. Because of that, removing >>> it as Peter suggests doesn't seem like a good idea to me. >> >> So what do people want to do with pg_migrator? I don't think calling >> pg_migrator a major features requires it to be in /bin. We added full >> text search to /contrib years ago and that was a major feature. > > > There is a reason people said that "8.3 comes with full text search" - > that's when it really became a major feature to the outside world. > Before that, it wasn't included in most comparisons. It was a PITA to > install (well, not install, but upgrading when you had it, etc). (once > you knew the insides, it was a major feature yes, but people didn't > know about that) > > 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? ....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
From: Tom Lane on 1 May 2010 11:42 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. 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 15:13 Tom Lane 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 one aspect we might be missing is that /contrib has uses beyond experimental stuff. For example, I don't believe anyone thinks /contrib/pgcrypto is going to get more stable than it is now, but it is in /contrib because it has functionality that is useful to a limited number of users. I think these /contrib modules fall into a similar category: auto_explain/ fuzzystrmatch/ hstore/ isn/ oid2name/ pageinspect/ pg_buffercache/ pg_freespacemap/ pg_standby/ pg_stat_statements/ pgbench/ pgrowlocks/ pgstattuple/ sslinfo/ unaccent/ That is over a third of the /contrib modules. I think pg_migrator falls into that category too --- it is only of use to people wanting to do a binary upgrade, and even then, they only run it once. And it is not something you are going to just fire up like psql. Here is the pg_migrator README: http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/pg-migrator/pg_migrator/README?rev=1.72&content-type=text/plain and the 15-step INSTALL file: http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/pg-migrator/pg_migrator/INSTALL?rev=1.56&content-type=text/plain 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. -- 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 15:31
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 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. ....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 |