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: Peter Eisentraut on 2 May 2010 06:22 On lör, 2010-05-01 at 17:26 -0400, Bruce Momjian wrote: > 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. Well, pg_resetxlog is also rarely run by most users. It started in contrib but was later moved to bin in order to show that it is fully supported. Also, I think the 15 steps are a bit inflated. Several of those steps are about building and installing various pieces of software. If you count that way, using PostgreSQL itself might also require about 12 steps. In a packaged environment that allows side-by-side installation of major versions (such as Debian or Windows), you need about 4 or 5 manual steps, and with a small script layer you need only 1 or 0. -- 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 2 May 2010 10:30 Robert Haas wrote: > 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. Tom's idea basically was that each version of pg_migrator would only support it current major version as a _target_. We would have to backpatch fixes to pg_migrator to previous major versions, and to pgfoundry if necessary. However, there isn't much code churn in pg_migrator anymore (as there was months before), so we should be OK. We already do such backpatching for all our other core code. I can easily keep all the code in each version of pg_migrator. However, pg_dump only supports loads into the _target_ major version, just like pg_migrator would do. I am unclear on which direction to take, but both are easy for me. -- 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 2 May 2010 10:31 Andrew Dunstan wrote: > > > Robert Haas wrote: > > I don't think it's going > > to be practical to retain all the migration code for every pair of > > versions forever, > > > > I thought the idea was just to support migration from version N to > version N+1. Oh, I will also support many older _source_ versions, like 8.3 and 8.4. The question is whether a pg_migrator in /contrib should support multiple _target_ versions. (Again, I assumed this discussion would be necessary, and is best done during beta.) -- 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 2 May 2010 11:39 Bruce Momjian <bruce(a)momjian.us> writes: > Andrew Dunstan wrote: >> I thought the idea was just to support migration from version N to >> version N+1. > Oh, I will also support many older _source_ versions, like 8.3 and 8.4. Really? Nobody else has bought into that, and it's not only pg_migrator that would have to go out of its way to support such cases. You're talking about cross-multi-version compatibility of on-disk formats too. 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 2 May 2010 11:45
Robert Haas wrote: > On Sat, May 1, 2010 at 11:31 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: > > Robert Haas wrote: > >> > >> ?I don't think it's going > >> to be practical to retain all the migration code for every pair of > >> versions forever, > > > > I thought the idea was just to support migration from version N to version > > N+1. > > I think that would be "good enough". But right now we can do better. > No reason to rip it out, is there? Again, we are talking about removing _target_ support for 8.4 in pg_migrator 9.0. It is hard to see why someone would use 9.0 /contrib pg_migrator to migrate from 8.3 to 8.4. -- 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 |