pg_upgrade docs
in [PgSql]
|
Prev: [HACKERS] tsvector pg_stats seems quite a bit off.
Next: Renaming '2010-Next' to '2010-6' in the commitfest app
From: Stefan Kaltenbrunner on 20 May 2010 09:24 On 05/19/2010 05:16 PM, Bruce Momjian wrote: > Andres Freund wrote: >> On Wednesday 19 May 2010 22:39:32 Bruce Momjian wrote: >>> There are some limitations when migrating from 8.3 to 8.4, but not when >>> migrating from 8.3 to 9.0, because we added a feature to 9.0. Can you >>> give a specific example? >> Didnt the 'name' alignment change? > > Uh, the heading above that item is: > > <title>Limitations in migrating <emphasis>from</> PostgreSQL > 8.3</title> > > What is unclear there? It covers going to 8.4 and 9.0. well the wording makes it kinda unclear on what happens if you go FROM 8.4 to 9.0. If there are no known limits we might want to add a small note saying so. If there are some we might want to restructure the paragraph a bit... Stefan -- 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 24 May 2010 13:43 Stefan Kaltenbrunner wrote: > On 05/19/2010 05:16 PM, Bruce Momjian wrote: > > Andres Freund wrote: > >> On Wednesday 19 May 2010 22:39:32 Bruce Momjian wrote: > >>> There are some limitations when migrating from 8.3 to 8.4, but not when > >>> migrating from 8.3 to 9.0, because we added a feature to 9.0. Can you > >>> give a specific example? > >> Didnt the 'name' alignment change? > > > > Uh, the heading above that item is: > > > > <title>Limitations in migrating <emphasis>from</> PostgreSQL > > 8.3</title> > > > > What is unclear there? It covers going to 8.4 and 9.0. > > well the wording makes it kinda unclear on what happens if you go FROM > 8.4 to 9.0. If there are no known limits we might want to add a small > note saying so. If there are some we might want to restructure the > paragraph a bit... Sorry for the delay in replying. The section you list is titled: F.31.4. Limitations in migrating from PostgreSQL 8.3 http://developer.postgresql.org/pgdocs/postgres/pgupgrade.html and the first sentence is: pg_upgrade will not work for a migration from 8.3 if a user column I have updated the paragraph to be: Upgrading from PostgreSQL 8.3 has additional restrictions not present when upgrading from later PostgreSQL releases. For example, pg_upgrade will not work for a migration from 8.3 if a user column is defined as: Can you suggest other wording? FYI, the items that affect only 8.3 to 8.4 migrations are no longer in the 9.0 pg_upgrade docs because we don't support 8.4 as a target anymore; specifically: Limitations In Migrating _to_ PostgreSQL 8.4 ---------------------------------------------------------- pg_migrator will not work if a user column is defined as: o a user-defined composite data type o a user-defined array data type o a user-defined enum data type You must drop any such columns and migrate them manually. You can see the full documentation here: http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pg-migrator/pg_migrator/README?rev=1.78&content-type=text/x-cvsweb-markup -- 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: Stefan Kaltenbrunner on 24 May 2010 14:59 On 05/24/2010 07:43 PM, Bruce Momjian wrote: > Stefan Kaltenbrunner wrote: >> On 05/19/2010 05:16 PM, Bruce Momjian wrote: >>> Andres Freund wrote: >>>> On Wednesday 19 May 2010 22:39:32 Bruce Momjian wrote: >>>>> There are some limitations when migrating from 8.3 to 8.4, but not when >>>>> migrating from 8.3 to 9.0, because we added a feature to 9.0. Can you >>>>> give a specific example? >>>> Didnt the 'name' alignment change? >>> >>> Uh, the heading above that item is: >>> >>> <title>Limitations in migrating<emphasis>from</> PostgreSQL >>> 8.3</title> >>> >>> What is unclear there? It covers going to 8.4 and 9.0. >> >> well the wording makes it kinda unclear on what happens if you go FROM >> 8.4 to 9.0. If there are no known limits we might want to add a small >> note saying so. If there are some we might want to restructure the >> paragraph a bit... > > Sorry for the delay in replying. The section you list is titled: > > F.31.4. Limitations in migrating from PostgreSQL 8.3 > > http://developer.postgresql.org/pgdocs/postgres/pgupgrade.html > > and the first sentence is: > > pg_upgrade will not work for a migration from 8.3 if a user column > > I have updated the paragraph to be: > > Upgrading from PostgreSQL 8.3 has additional restrictions not present > when upgrading from later PostgreSQL releases. For example, > pg_upgrade will not work for a migration from 8.3 if a user column > is defined as: > > Can you suggest other wording? hmm that seems better thanks, however I just noticed that we don't have a "general limitations" section. The way the docs are now done suggests that there are not limitations at all (except for the two warnings in the migration guide). Is pg_upgrade really up to the point where it can fully replace pg_dump & pg_restore independent of the loaded (contrib) or even third party modules(like postgis or custom datatypes etc)? Stefan -- 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 24 May 2010 15:11 Stefan Kaltenbrunner wrote: > > I have updated the paragraph to be: > > > > Upgrading from PostgreSQL 8.3 has additional restrictions not present > > when upgrading from later PostgreSQL releases. For example, > > pg_upgrade will not work for a migration from 8.3 if a user column > > is defined as: > > > > Can you suggest other wording? > > hmm that seems better thanks, however I just noticed that we don't have > a "general limitations" section. The way the docs are now done suggests > that there are not limitations at all (except for the two warnings in > the migration guide). Is pg_upgrade really up to the point where it can > fully replace pg_dump & pg_restore independent of the loaded (contrib) > or even third party modules(like postgis or custom datatypes etc)? Yea, that's about right. I can add limiations if you want. ;-) The only open pg_upgrade items are the ones on our TODO list: http://wiki.postgresql.org/wiki/Todo (I can't give you a URL hash-reference to the section because it doesn't work on Firefox and no one seems to be able to fix it.) -- 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 24 May 2010 15:16 On Mon, May 24, 2010 at 3:11 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > Stefan Kaltenbrunner wrote: >> > I have updated the paragraph to be: >> > >> > Upgrading from PostgreSQL 8.3 has additional restrictions not present >> > when upgrading from later PostgreSQL releases. For example, >> > pg_upgrade will not work for a migration from 8.3 if a user column >> > is defined as: >> > >> > Can you suggest other wording? >> >> hmm that seems better thanks, however I just noticed that we don't have >> a "general limitations" section. The way the docs are now done suggests >> that there are not limitations at all (except for the two warnings in >> the migration guide). Is pg_upgrade really up to the point where it can >> fully replace pg_dump & pg_restore independent of the loaded (contrib) >> or even third party modules(like postgis or custom datatypes etc)? > > Yea, that's about right. I can add limiations if you want. ;-) I don't believe this. For one thing, I am pretty sure that if there are ABI differences between loadable modules between the old and new cluster, hilarity will ensue. > The only open pg_upgrade items are the ones on our TODO list: > > http://wiki.postgresql.org/wiki/Todo > > (I can't give you a URL hash-reference to the section because it doesn't > work on Firefox and no one seems to be able to fix it.) It works OK for me. The link to /contrib/pg_upgrade within the nav section at the top righthand corner of the page seems to work just fine. http://wiki.postgresql.org/wiki/Todo#.2Fcontrib.2Fpg_upgrade -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: [HACKERS] tsvector pg_stats seems quite a bit off. Next: Renaming '2010-Next' to '2010-6' in the commitfest app |