Обсуждение: 7.4 --> 8.0/8.1 upgrade
Hello admins!
i need to collect as much information
pro/cons on a possible upgrade from
7.4 ---> 8.0/8.1 version
Aside from getting our users vote on this, I wanted to ask you first
in order to collect any possible issues one might run into from upgrading to such
versions.
Thanks in advance!
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.
i need to collect as much information
pro/cons on a possible upgrade from
7.4 ---> 8.0/8.1 version
Aside from getting our users vote on this, I wanted to ask you first
in order to collect any possible issues one might run into from upgrading to such
versions.
Thanks in advance!
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.
On Tue, 2006-03-28 at 19:47, sh test wrote: > Hello admins! > > i need to collect as much information > > pro/cons on a possible upgrade from > > 7.4 ---> 8.0/8.1 version > > Aside from getting our users vote on this, I wanted to ask you first > in order to collect any possible issues one might run into from > upgrading to such > versions. Downside: You gotta dump and reload, or use slony to minimize the downtime, but you need a spare machine to do that. Upside: Everything else. PostgreSQL 8.x series has a lot of performance improvements.
Scott Marlowe wrote: >On Tue, 2006-03-28 at 19:47, sh test wrote: > > >>Hello admins! >> >>i need to collect as much information >> >>pro/cons on a possible upgrade from >> >>7.4 ---> 8.0/8.1 version >> >>Aside from getting our users vote on this, I wanted to ask you first >>in order to collect any possible issues one might run into from >>upgrading to such >>versions. >> >> > >Downside: You gotta dump and reload, or use slony to minimize the >downtime, but you need a spare machine to do that. > >Upside: Everything else. PostgreSQL 8.x series has a lot of >performance improvements. > > When I upgraded from 7.4.2 to 8.1.3, I lost the oid fields in some tables which caused some issues with one application. I suspect that the better path is to upgrade (without dump/reload) to the most recent 7.4 release and then dump/reload when upgrading to 8.1.x but I am not 100% sure. If you don't WANT OID's in your table (they were dropped for a reason, you know), then this is not a concern. Best Wishes, Chris Travers Metatron Technology Consulting
Вложения
Chris Travers написа: > Scott Marlowe wrote: > >> On Tue, 2006-03-28 at 19:47, sh test wrote: >> >> >>> Hello admins! >>> >>> i need to collect as much information >>> >>> pro/cons on a possible upgrade from >>> >>> 7.4 ---> 8.0/8.1 version >>> >>> Aside from getting our users vote on this, I wanted to ask you first >>> in order to collect any possible issues one might run into from >>> upgrading to such >>> versions. >>> >> >> Downside: You gotta dump and reload, or use slony to minimize the >> downtime, but you need a spare machine to do that. >> Upside: Everything else. PostgreSQL 8.x series has a lot of >> performance improvements. >> >> > When I upgraded from 7.4.2 to 8.1.3, I lost the oid fields in some > tables which caused some issues with one application. Probably because in 8.1 the value for the "default_with_oids" parameter is "false". If you had tried to set it to "true" (at least for duration of the restore) then you would have not lost those OIDs. > > I suspect that the better path is to upgrade (without dump/reload) to > the most recent 7.4 release and then dump/reload when upgrading to 8.1.x > but I am not 100% sure. > > If you don't WANT OID's in your table (they were dropped for a reason, > you know), then this is not a concern. -- Milen A. Radev
On Tue, 2006-03-28 at 21:00, Chris Travers wrote: > When I upgraded from 7.4.2 to 8.1.3, I lost the oid fields in some > tables which caused some issues with one application. > > I suspect that the better path is to upgrade (without dump/reload) to > the most recent 7.4 release and then dump/reload when upgrading to 8.1.x > but I am not 100% sure. > > If you don't WANT OID's in your table (they were dropped for a reason, > you know), then this is not a concern. The only problems I've run into have been character set encoding issues, which were fixed by iconv rather easily. Since I set up the databases we used, and didn't inherit them, we don't have any craziness like OIDs used as keys and such. yeah!
On Mar 28, 2006, at 7:55 PM, Scott Marlowe wrote: > On Tue, 2006-03-28 at 19:47, sh test wrote: >> Hello admins! >> >> i need to collect as much information >> >> pro/cons on a possible upgrade from >> >> 7.4 ---> 8.0/8.1 version >> >> Aside from getting our users vote on this, I wanted to ask you first >> in order to collect any possible issues one might run into from >> upgrading to such >> versions. > > Downside: You gotta dump and reload, or use slony to minimize the > downtime, but you need a spare machine to do that. Actually, there's no reason you shouldn't be able to use slony to upgrade on the same machine, provided that machine has enough resources to run two installs of PostgreSQL and the databases simultaneously. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
jnasby@pervasive.com (Jim Nasby) writes: > On Mar 28, 2006, at 7:55 PM, Scott Marlowe wrote: > >> On Tue, 2006-03-28 at 19:47, sh test wrote: >>> Hello admins! >>> >>> i need to collect as much information >>> >>> pro/cons on a possible upgrade from >>> >>> 7.4 ---> 8.0/8.1 version >>> >>> Aside from getting our users vote on this, I wanted to ask you first >>> in order to collect any possible issues one might run into from >>> upgrading to such >>> versions. >> >> Downside: You gotta dump and reload, or use slony to minimize the >> downtime, but you need a spare machine to do that. > > Actually, there's no reason you shouldn't be able to use slony to > upgrade on the same machine, provided that machine has enough > resources to run two installs of PostgreSQL and the databases > simultaneously. And note that the second instance only needs to cope with the update traffic. If the 7.4-based backend is servicing a lot of queries as well, that's load that won't be on the replica. -- (format nil "~S@~S" "cbbrowne" "acm.org") http://www3.sympatico.ca/cbbrowne/lisp.html "When I was a boy of fourteen, my father was so ignorant I could hardly stand to have the old man around. But when I got to be twenty-one, I was astonished at how much the old man had learned in seven years." -- Mark Twain