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 2 May 2010 12:57 Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: > > Yeah. It's not uncommon to want to upgrade by more than one release at > > a time, and I haven't heard any reason why we should arbitrarily > > refuse to support that. Of course we may need to do that eventually > > for some specific reason, but it seems like we should only consider > > imposing such a restriction in the face of a tangible need. > > I wasn't suggesting that we should arbitrarily refuse to support cases > that would work otherwise. What I *was* saying is that the community > has not bought into doing any extra work to support > cross-multiple-version migrations, and I don't think it will do so. > It would be a mistake to give users the impression that such cases can > be expected to work in future. In particular we should not provide a > documentation table that is set up to give the impression that > multi-version upgrades are going to be supported. The docs should be > written to make it clear that one-version-at-a-time is the normal case, > and any cases where you can take a shortcut should be documented as > exceptions. Well, that is going to make the documentation more complicated than it already is. Why mention a process in 9.0 that no one needs to use? I am not writing the docs for some hypothetical release, but for 9.0. When we have some restriction, we can document that. My guess is that 9.2 will be able to upgrade from 8.3, 8.4, 9.0, and 9.1, but that going to 9.5 will require you to go to 9.2 first, run some script, then upgrade to 9.5; again all hypothetical. I think we can require people using pg_migrator to read matching documentation for that major version of pg_migrator, and pg_migrator will enforce any restrictions we come up with in the future. For example, I assume there will be some major version of Postgres where pg_migrator will not work at all. -- 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 13:21 Peter Eisentraut wrote: > 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. Yea, it is like pg_resetxlog. The only counter-argument I can think of is that we decided that everyone should have the pg_resetxlog binary available, and not have to scramble around to install it in case of a problem, but I will admit that is a thin argument. > 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. Well, that is good news. -- 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 15:06 Bruce Momjian wrote: > Well, that is going to make the documentation more complicated than it > already is. Why mention a process in 9.0 that no one needs to use? I > am not writing the docs for some hypothetical release, but for 9.0. > When we have some restriction, we can document that. > > My guess is that 9.2 will be able to upgrade from 8.3, 8.4, 9.0, and > 9.1, but that going to 9.5 will require you to go to 9.2 first, run some > script, then upgrade to 9.5; again all hypothetical. I think we can > require people using pg_migrator to read matching documentation for that > major version of pg_migrator, and pg_migrator will enforce any > restrictions we come up with in the future. For example, I assume there > will be some major version of Postgres where pg_migrator will not work > at all. I do think we are going to have to mention new pg_migrator restrictions in the major release notes for future versions. -- 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: Andrew Dunstan on 2 May 2010 15:30 Bruce Momjian wrote: > For example, I assume there > will be some major version of Postgres where pg_migrator will not work > at all. > > We need to be thinking more now about such a contingency. Postgres use in very large installations is now at such a level that requiring a pg_dump/pg_restore is really not an option for many users. If pg_migrator is not always going to work then we need to be addressing that now, or else it is at best a stop-gap. ISTM some sort of page layout versioning scheme might be at least part of what we'll need in the medium term. cheers andrew -- 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 15:34
Andrew Dunstan wrote: > > > Bruce Momjian wrote: > > For example, I assume there > > will be some major version of Postgres where pg_migrator will not work > > at all. > > > > > > We need to be thinking more now about such a contingency. Postgres use > in very large installations is now at such a level that requiring a > pg_dump/pg_restore is really not an option for many users. If > pg_migrator is not always going to work then we need to be addressing > that now, or else it is at best a stop-gap. ISTM some sort of page > layout versioning scheme might be at least part of what we'll need in > the medium term. Yes, my bet is that when we do need to change the page format, we will either use a conversion-on-read process or some external tool to do the conversion. pg_migrator does have code to do page conversions but it has never been used. If you are using pg_migrator in copy mode, we might be able to do page conversion during the copy, but for link mode, that is not possible. -- 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 |