[HACKERS] pg_upgrade docs

2012-09-04 Thread Bruce Momjian
This doc sentence about pg_upgrade is now inaccurate:

   If doing --check with a running old server of a pre-9.1 version,
   and the old server is using a Unix-domain socket directory that is
   different from the default built into the new PostgreSQL
   installation, set PGHOST to point to the socket location of the
   old server.  (This is not relevant on Windows.)

The new detail is that this also affects non-live check and non-check
upgrades because pg_ctl -w doesn't work for pre-9.1 servers with the
socket in the current directory --- that was not known when this
documentation paragraph was written.

Applied doc patch attached.  The wording became pretty complex so I
tried to simplify it.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/pgupgrade.sgml b/doc/src/sgml/pgupgrade.sgml
new file mode 100644
index 9e43f3c..301222c
*** a/doc/src/sgml/pgupgrade.sgml
--- b/doc/src/sgml/pgupgrade.sgml
*** psql --username postgres --file script.s
*** 520,530 

  

!If doing --check with a running old server of a pre-9.1 version,
!and the old server is using a Unix-domain socket directory that is
!different from the default built into the new PostgreSQL
!installation, set PGHOST to point to the socket location of the
!old server.  (This is not relevant on Windows.)

  

--- 520,529 

  

!If using a pre-9.1 old server that is using a non-default Unix-domain
!socket directory or a default that differs from the default of the
!new cluster, set PGHOST to point to the old server's socket
!location.  (This is not relevant on Windows.)

  


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-25 Thread Bruce Momjian
Robert Haas wrote:
> On Mon, May 24, 2010 at 11:35 PM, Bruce Momjian  wrote:
> > Have you read the docs? ?It does mention the issue with /contrib and
> > stuff. ?How do I document a limitation I don't know about? ?This is all
> > very vague. ?Please suggest some wording.
> 
> OK, here's an attempt.  Please fact-check.
> 
> --
> 
> General Limitations
> 
> pg_upgrade relies on binary compatibility between the old and new
> on-disk formats, including the on-disk formats of individual data
> types.  pg_upgrade attempts to detect cases in which the on-disk
> format has changed; for example, it verifies that the old and new
> clusters have the same value for --enable-integer-datetimes.  However,
> there is no systematic way for pg_upgrade to detect problems of this
> type; it has hard-coded knowledge of the specific cases known to exist
> in core PostgreSQL, including /contrib.  If third-party or
> user-defined data types or access methods are used, it is the user's
> responsibility to verify that the versions loaded into the old and new
> clusters use compatible on-disk formats.  If they do not, pg_upgrade
> may appear to work but subsequently crash or silently corrupt data.

OK, I have added a mention of the issues above, in a more abbreviated
format.

> pg_upgrade also relies on ABI compatibility between modules loaded
> into the old and new clusters.  For example, if an SQL function in the
> old cluster is defined to call a particular C function, pg_upgrade
> will recreate SQL function in the new cluster and will configure it to
> call the same C function.  If no such C function can be found by the
> new cluster, pg_upgrade will simply fail.  However, if a C function of
> the same name exists in the new cluster, but expects a different
> number of arguments or different types of arguments, then it is likely
> to crash the system when called.  In the worst case, data corruption
> could result.

These issues are not unique to pg_upgrade, and could happen even in a
pg_dump restore.

> Also, the following sentence appears not to fit with our "only to 9.0"
> policy: "For Windows users, note that due to different integer
> datetimes settings used by the one-click installer and the MSI
> installer, it is only possible to upgrade from version 8.3 of the
> one-click distribution to version 8.4 of the one-click distribution.
> It is not possible to upgrade from the MSI installer to the one-click
> installer."

Agreed.  I added a "8.4 or later" mention.  It is not worth calling it
"9.0 or later" because then I would have to update this mention for
every major release.

Applied patch attached.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com
Index: doc/src/sgml/pgupgrade.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/pgupgrade.sgml,v
retrieving revision 1.10
diff -c -c -r1.10 pgupgrade.sgml
*** doc/src/sgml/pgupgrade.sgml	24 May 2010 17:43:39 -	1.10
--- doc/src/sgml/pgupgrade.sgml	25 May 2010 14:50:36 -
***
*** 16,21 
--- 16,31 
9.0.1 -> 9.0.4.
   
  
+  
+   pg_upgrade works because, though new features are
+   regularly added to Postgres major releases, the internal data storage
+   format rarely changes.  pg_upgrade does its best to
+   make sure the old and new clusters are binary-compatible, e.g.  by
+   checking for compatible compile-time settings.  It is important that
+   any external modules are also binary compatibile, though this cannot
+   be checked by pg_upgrade.
+  
+ 
   
Supported Versions
  
***
*** 440,446 

Limitations in migrating from PostgreSQL 8.3
   
-  

 Upgrading from PostgreSQL 8.3 has additional restrictions not present
 when upgrading from later PostgreSQL releases.  For example,
--- 450,455 
***
*** 502,509 
 For Windows users, note that due to different integer datetimes settings
 used by the one-click installer and the MSI installer, it is only
 possible to upgrade from version 8.3 of the one-click distribution to
!version 8.4 of the one-click distribution. It is not possible to upgrade
!from the MSI installer to the one-click installer.

   
  
--- 511,518 
 For Windows users, note that due to different integer datetimes settings
 used by the one-click installer and the MSI installer, it is only
 possible to upgrade from version 8.3 of the one-click distribution to
!version 8.4 or later of the one-click distribution. It is not
!possible to upgrade from the MSI installer to the one-click installer.

   
  

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-25 Thread Robert Haas
On Mon, May 24, 2010 at 11:35 PM, Bruce Momjian  wrote:
> Have you read the docs?  It does mention the issue with /contrib and
> stuff.  How do I document a limitation I don't know about?  This is all
> very vague.  Please suggest some wording.

OK, here's an attempt.  Please fact-check.

--

General Limitations

pg_upgrade relies on binary compatibility between the old and new
on-disk formats, including the on-disk formats of individual data
types.  pg_upgrade attempts to detect cases in which the on-disk
format has changed; for example, it verifies that the old and new
clusters have the same value for --enable-integer-datetimes.  However,
there is no systematic way for pg_upgrade to detect problems of this
type; it has hard-coded knowledge of the specific cases known to exist
in core PostgreSQL, including /contrib.  If third-party or
user-defined data types or access methods are used, it is the user's
responsibility to verify that the versions loaded into the old and new
clusters use compatible on-disk formats.  If they do not, pg_upgrade
may appear to work but subsequently crash or silently corrupt data.

pg_upgrade also relies on ABI compatibility between modules loaded
into the old and new clusters.  For example, if an SQL function in the
old cluster is defined to call a particular C function, pg_upgrade
will recreate SQL function in the new cluster and will configure it to
call the same C function.  If no such C function can be found by the
new cluster, pg_upgrade will simply fail.  However, if a C function of
the same name exists in the new cluster, but expects a different
number of arguments or different types of arguments, then it is likely
to crash the system when called.  In the worst case, data corruption
could result.

--

Also, the following sentence appears not to fit with our "only to 9.0"
policy: "For Windows users, note that due to different integer
datetimes settings used by the one-click installer and the MSI
installer, it is only possible to upgrade from version 8.3 of the
one-click distribution to version 8.4 of the one-click distribution.
It is not possible to upgrade from the MSI installer to the one-click
installer."

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-24 Thread Bruce Momjian
Robert Haas wrote:
> On Mon, May 24, 2010 at 5:50 PM, Bruce Momjian  wrote:
> > What is your point?
> 
> My point is that I think Stefan has a good point when he says this:
> 
> >> >> >> 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)?
> 
> I think he is quite right to be concerned about these issues and if
> the limitations in this area are not well-documented so that users can
> easily be aware of them, then IMHO that is something we should
> correct.

Have you read the docs?  It does mention the issue with /contrib and
stuff.  How do I document a limitation I don't know about?  This is all
very vague.  Please suggest some wording.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-24 Thread Robert Haas
On Mon, May 24, 2010 at 5:50 PM, Bruce Momjian  wrote:
> What is your point?

My point is that I think Stefan has a good point when he says this:

>> >> >> 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)?

I think he is quite right to be concerned about these issues and if
the limitations in this area are not well-documented so that users can
easily be aware of them, then IMHO that is something we should
correct.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-24 Thread Robert Haas
On Mon, May 24, 2010 at 5:38 PM, Dave Page  wrote:
> On Mon, May 24, 2010 at 5:20 PM, Robert Haas  wrote:
>
 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
>>>
>>> The problem is that the "Contents" menu on the top right of the page
>>> doesn't allow a clickable link to that section, and many others.
>>
>> It does for me...
>
> Doesn't here. FYI, neither do others such as 2.6, 2.7, 6.1 & 6.11

Oh, interesting.  2.6 and 2.7 don't work for me, but 6.1 and 6.11 do.
That is really odd.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-24 Thread Bruce Momjian
Robert Haas wrote:
> On Mon, May 24, 2010 at 3:41 PM, Bruce Momjian  wrote:
> > Robert Haas wrote:
> >> On Mon, May 24, 2010 at 3:11 PM, Bruce Momjian  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.
> >
> > Well, the point is that our existing code doesn't have any
> > incompatibilites that I know of. ?We could certainly add some in 9.1.
> 
> Yes, or third-party vendors could add some for us.  We can't guarantee
> this in general.

What is your point?

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-24 Thread Dave Page
On Mon, May 24, 2010 at 5:20 PM, Robert Haas  wrote:

>>> 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
>>
>> The problem is that the "Contents" menu on the top right of the page
>> doesn't allow a clickable link to that section, and many others.
>
> It does for me...

Doesn't here. FYI, neither do others such as 2.6, 2.7, 6.1 & 6.11


-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-24 Thread Robert Haas
On Mon, May 24, 2010 at 3:41 PM, Bruce Momjian  wrote:
> Robert Haas wrote:
>> On Mon, May 24, 2010 at 3:11 PM, Bruce Momjian  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.
>
> Well, the point is that our existing code doesn't have any
> incompatibilites that I know of.  We could certainly add some in 9.1.

Yes, or third-party vendors could add some for us.  We can't guarantee
this in general.

>> > 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
>
> The problem is that the "Contents" menu on the top right of the page
> doesn't allow a clickable link to that section, and many others.

It does for me...

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-24 Thread Bruce Momjian
Robert Haas wrote:
> On Mon, May 24, 2010 at 3:11 PM, Bruce Momjian  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.

Well, the point is that our existing code doesn't have any
incompatibilites that I know of.  We could certainly add some in 9.1.

> > 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

The problem is that the "Contents" menu on the top right of the page
doesn't allow a clickable link to that section, and many others.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-24 Thread Robert Haas
On Mon, May 24, 2010 at 3:11 PM, Bruce Momjian  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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-24 Thread Bruce Momjian
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  http://momjian.us
  EnterpriseDB http://enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-24 Thread Stefan Kaltenbrunner

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:

   Limitations in migratingfrom  PostgreSQL
   8.3

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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-24 Thread Bruce Momjian
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:
> > 
> >   Limitations in migrating from PostgreSQL
> >   8.3
> > 
> > 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  http://momjian.us
  EnterpriseDB http://enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-20 Thread Stefan Kaltenbrunner
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:
> 
>   Limitations in migrating from PostgreSQL
>   8.3
> 
> 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-19 Thread Bruce Momjian
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:

  Limitations in migrating from PostgreSQL
  8.3

What is unclear there?  It covers going to 8.4 and 9.0.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-19 Thread Andres Freund
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?

Andres 

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-19 Thread Bruce Momjian
Alvaro Herrera wrote:
> Excerpts from Stefan Kaltenbrunner's message of mi?? may 19 15:53:18 -0400 
> 2010:
> > While looking at the docs for pg_upgrade I noticed some stuff that the
> > following patch attempts to at least partly address.
> 
> Surely this para can be removed?
> 
>  
>   If you are using tablespaces and migrating to 8.4 or earlier, there must
> - be sufficient directory permissions to allow pg_upgrade to rename each
> + be sufficient directory permissions to allow pg_upgrade 
> to rename each
>   tablespace directory to add a ".old" suffix.
>  

Ah, yes, removed.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-19 Thread Bruce Momjian
Stefan Kaltenbrunner wrote:
> While looking at the docs for pg_upgrade I noticed some stuff that the
> following patch attempts to at least partly address.
> There is quite some confusion going on between using "Postgres" and
> PostgreSQL, I changed that to the later because that is how we spell the
> productname in all the other parts of the docs, also added some further
> markups and crossreferences to other docs.

Applied.

> Stuff that seems to need further work is more or less the "limitations"
> section, I don't think there are only issues when upgrade from 8.3 but
> also from 8.4 (though not as much iirc) there is also the rather bold

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?

> "we will support upgrades from every snapshot and alpha release" which
> seems very optimistic...

Well, I didn't say "every".

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pg_upgrade docs

2010-05-19 Thread Alvaro Herrera
Excerpts from Stefan Kaltenbrunner's message of mié may 19 15:53:18 -0400 2010:
> While looking at the docs for pg_upgrade I noticed some stuff that the
> following patch attempts to at least partly address.

Surely this para can be removed?

 
  If you are using tablespaces and migrating to 8.4 or earlier, there must
- be sufficient directory permissions to allow pg_upgrade to rename each
+ be sufficient directory permissions to allow pg_upgrade 
to rename each
  tablespace directory to add a ".old" suffix.
 

-- 

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] pg_upgrade docs

2010-05-19 Thread Stefan Kaltenbrunner
While looking at the docs for pg_upgrade I noticed some stuff that the
following patch attempts to at least partly address.
There is quite some confusion going on between using "Postgres" and
PostgreSQL, I changed that to the later because that is how we spell the
productname in all the other parts of the docs, also added some further
markups and crossreferences to other docs.
Stuff that seems to need further work is more or less the "limitations"
section, I don't think there are only issues when upgrade from 8.3 but
also from 8.4 (though not as much iirc) there is also the rather bold
"we will support upgrades from every snapshot and alpha release" which
seems very optimistic...


Stefan
Index: doc/src/sgml/pgupgrade.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/pgupgrade.sgml,v
retrieving revision 1.5
diff -u -r1.5 pgupgrade.sgml
--- doc/src/sgml/pgupgrade.sgml	18 May 2010 15:41:36 -	1.5
+++ doc/src/sgml/pgupgrade.sgml	19 May 2010 19:33:07 -
@@ -9,10 +9,10 @@
 
  
   pg_upgrade (formerly called pg_migrator) allows data
-  stored in Postgres data files to be migrated to a later Postgres
+  stored in PostgreSQL data files to be migrated to a later PostgreSQL
   major version without the data dump/reload typically required for
   major version upgrades, e.g. from 8.4.7 to the current major release
-  of Postgres.  It is not required for minor version upgrades, e.g.
+  of PostgreSQL.  It is not required for minor version upgrades, e.g
   9.0.1 -> 9.0.4.
  
 
@@ -21,7 +21,7 @@
 
   
pg_upgrade supports upgrades from 8.3.X and later to the current
-   major release of Postgres, including snapshot and alpha releases.
+   major release of PostgreSQL, including snapshot and alpha releases.
 
   
 
@@ -37,17 +37,17 @@
 
  
 
- If you are using a version-specific PostgreSQL install directory, e.g.
+ If you are using a version-specific installation directory, e.g.
  /opt/PostgreSQL/8.4, you do not need to move the old cluster. The
  one-click installers all use version-specific install directories.
 
  
 
- If your PostgreSQL install directory is not version-specific, e.g.
- /usr/local/pgsql, it is necessary to move the current Postgres install
- directory so it does not interfere with the new Postgres installation.
- Once the current Postgres server is shut down, it is safe to rename the
- Postgres install directory; assuming the old directory is
+ If your installation directory is not version-specific, e.g.
+ /usr/local/pgsql, it is necessary to move the current PostgreSQL install
+ directory so it does not interfere with the new PostgreSQL installation.
+ Once the current PostgreSQL server is shut down, it is safe to rename the
+ PostgreSQL install directory; assuming the old directory is
  /usr/local/pgsql, you can do:
  
 
@@ -58,26 +58,26 @@
  
 
  If you are using tablespaces and migrating to 8.4 or earlier, there must
- be sufficient directory permissions to allow pg_upgrade to rename each
+ be sufficient directory permissions to allow pg_upgrade to rename each
  tablespace directory to add a ".old" suffix.
 

  

 
- For PostgreSQL source installs, build the new PostgreSQL version
+ For source installs, build the new version
 
  
 
- Build the new Postgres source with configure flags that are compatible
- with the old cluster. pg_upgrade will check pg_controldata to make
+ Build the new PostgreSQL source with configure flags that are compatible
+ with the old cluster. pg_upgrade will check pg_controldata to make
  sure all settings are compatible before starting the upgrade.
 

  

 
- Install the new Postgres binaries
+ Install the new PostgreSQL binaries
 
  
 
@@ -109,8 +109,10 @@
 
  
 
- Initialize the new cluster using initdb. Again, use compatible initdb
- flags that match the old cluster (pg_upgrade will check that too.) Many
+ Initialize the new cluster ,initdb.
+ Again, use compatible initdb
+ flags that match the old cluster. Many
  prebuilt installers do this step automatically. There is no need to
  start the new cluster.
 
@@ -139,8 +141,8 @@
  pg_upgrade will connect to the old and new servers several times,
  so you might want to set authentication to trust in
  pg_hba.conf, or if using md5 authentication,
- use a pgpass file to avoid being prompted repeatedly
- for a password.
+ use a ~/.pgpass file (see )
+ to avoid being prompted repeatedly for a password.
 

  
@@ -167,20 +169,20 @@
  or
  
 
-NET STOP pgsql-8.3  (different service name)
+NET STOP pgsql-8.3  (PostgreSQL 8.3 and older used a different service name)
 
 

  

 
- Run pg_upgrade
+ Run pg_upgrade
 
  
 
- Always run the pg_upgrade binary in the ne