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 11:49 Tom Lane wrote: > Andrew Dunstan <andrew(a)dunslane.net> writes: > > 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. > > Yeah. I think trying to do more than that is just going to make things > messy. For example, we added features to pg_dump and the core server > since 8.4 to help pg_migrator do its thing. Trying to make the same > pg_migrator code support cases with and without those features available > is going to complicate the code, not to mention the documentation, > enormously. As a summary, let me list the migrations pg_migrator supports: 8.3 -> 8.4 8.4 -> 9.0 8.3 -> 9.0 Surprisingly, it is 8.3 -> 8.4 that has the most restrictions because it doesn't have access to the features we added in Postgres 9.0. Tom is right that the code could be cleaned up if we removed 8.3 -> 8.4, but more importantly the documentation would be clearer. > To the extent that future bug fixes are relevant to multiple versions > of pg_migrator, we could just apply them to multiple branches, same as > we manage such fixes for the core code. I don't see that trying to > have a single version of pg_migrator is going to make things easier > anywhere. Yea, that is probably right. We can enforce in pg_migrator that you can only migrate to the matching major version you are using in /contrib. -- 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 12:01 Tom Lane wrote: > 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. Well, it works. I have a test suite that I run regularly. Because of the way pg_migrator works it is pretty painless to support multiple _source_ major versions. The binary format issue is relevant, but until we have a way to remove the old binary format, I don't see much value in supporting just one source version. For example, we don't have any system now to remove the HEAP_MOVED_OFF and HEAP_MOVED_IN heap bits so effectively major versions have to support them forever. Now, if we develop a system where a version would _remove_ the old data format, we would then specify that pg_migrator can only migrate _from_ one major version, and you would have to run a script to remove the old data format. For example, migrating from 9.0 to 9.2 would requiring migrating from 9.0 to 9.1 with pg_migrator, updating the data pages to 9.1 format, then using pg_migrator again to migrate from 9.1 to 9.2, but of course, we are not there yet. My guess is that when that happens we would just document/enforce it in pg_migrator, but I don't see why we would arbitrarily restrict pg_migrator at this time. -- 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 2 May 2010 12:21 On May 2, 2010, at 12:01 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > Tom Lane wrote: >> 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. > > Well, it works. I have a test suite that I run regularly. Because of > the way pg_migrator works it is pretty painless to support multiple > _source_ major versions. > > The binary format issue is relevant, but until we have a way to remove > the old binary format, I don't see much value in supporting just one > source version. For example, we don't have any system now to remove > the > HEAP_MOVED_OFF and HEAP_MOVED_IN heap bits so effectively major > versions > have to support them forever. Now, if we develop a system where a > version would _remove_ the old data format, we would then specify that > pg_migrator can only migrate _from_ one major version, and you would > have to run a script to remove the old data format. For example, > migrating from 9.0 to 9.2 would requiring migrating from 9.0 to 9.1 > with > pg_migrator, updating the data pages to 9.1 format, then using > pg_migrator again to migrate from 9.1 to 9.2, but of course, we are > not > there yet. > > My guess is that when that happens we would just document/enforce it > in > pg_migrator, but I don't see why we would arbitrarily restrict > pg_migrator at this time. 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. ....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: Bruce Momjian on 2 May 2010 12:29 Robert Haas wrote: > > My guess is that when that happens we would just document/enforce it > > in > > pg_migrator, but I don't see why we would arbitrarily restrict > > pg_migrator at this time. > > 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. Yea, we will need it one day, and if pg_migrator was more tied to system table changes and such, it would be smart to do it now, but if you look at the C code you will see that most of the effort is related to compatibility with the _target_ major version, not the _source_ major version, and by definition, the source major version never changes as we release new major versions. (Remember, pg_dump already does the heavy lifting of moving our database schema to the new major version.) A lot of understanding pg_migrator is understanding the source/target matrix of compatibility --- something we as a community have not thought about very much at this level. -- 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 12:45
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. 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 |