Обсуждение: 7.4 --> 8.0/8.1 upgrade

Поиск
Список
Период
Сортировка

7.4 --> 8.0/8.1 upgrade

От
sh test
Дата:
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.

Re: 7.4 --> 8.0/8.1 upgrade

От
Scott Marlowe
Дата:
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.

Re: 7.4 --> 8.0/8.1 upgrade

От
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.

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

Вложения

Re: 7.4 --> 8.0/8.1 upgrade

От
"Milen A. Radev"
Дата:
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

Re: 7.4 --> 8.0/8.1 upgrade

От
Scott Marlowe
Дата:
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!

Re: 7.4 --> 8.0/8.1 upgrade

От
Jim Nasby
Дата:
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



Re: 7.4 --> 8.0/8.1 upgrade

От
Chris Browne
Дата:
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