Upgrade Procedures 
Author Message
 Upgrade Procedures

Quote:
>The whole "vaccuum" concept is, IMHO, one of the weakest aspects of
>PostgreSQL.

Speaking of which, we love Postgresql, but I am concerned about the fact
that major upgrades require unloading and reloading the database.  We are
small enough now, so it is not really a concern.  I cannot imagine this
happening with really large database clusters (>50-100gigs).

I know for minor releases, there are upgrade programs to let this happen in
place.  Is there any plan for not always having to load and reload in the
future?

----------------------------------------------------------------------------
----------------------------------
Naomi Walker
Eldorado Computing, Inc
Chief Information Officer

602-604-3100 x242

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster



Wed, 22 Jun 2005 00:10:30 GMT
 Upgrade Procedures

Quote:
> Speaking of which, we love Postgresql, but I am concerned about the fact
> that major upgrades require unloading and reloading the database.  We
are
> small enough now, so it is not really a concern.  I cannot imagine this
> happening with really large database clusters (>50-100gigs).

> I know for minor releases, there are upgrade programs to let this happen
in
> place.  Is there any plan for not always having to load and reload in
the
> future?

  It can be a pain in the butt, but I'm glad that it's done that way.  I'd
rather take a small bite up front rather than have the development team
incorporate backwards-compatibility, which even if it COULD be done, would
probably hinder development much more than would be prudent.

steve

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster



Wed, 22 Jun 2005 01:21:49 GMT
 Upgrade Procedures

Quote:

>> I know for minor releases, there are upgrade programs to let this happen
>> in
>> place.  Is there any plan for not always having to load and reload in
>> the
>> future?
>   It can be a pain in the butt, but I'm glad that it's done that way.  I'd
> rather take a small bite up front rather than have the development team
> incorporate backwards-compatibility, which even if it COULD be done, would
> probably hinder development much more than would be prudent.

This is, um, an ancient topic.  See thread "Upgrading rant" now in
progress on pgsql-hackers for the latest rehash of the arguments ...

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Wed, 22 Jun 2005 04:48:56 GMT
 
 [ 3 post ] 

 Relevant Pages 

1. Upgrade Procedures?

2. Upgrade Procedures

3. Procedure for upgrading to Office XP?

4. sql2ksp3 upgrade: Error executing stored procedure via ODBC

5. Store procedures slow after upgrade

6. -9753 procedure execution error with 9.21.UC3 upgrade

7. Upgrading to Stored Procedures

8. Upgrade SQL 6.5 to 7.0 (Stored Procedures)

9. Slow stored procedures after 2000 upgrade

10. Procedure for 6.5 to 7.0 upgrade

11. Extremely poor stored procedure performance after upgrade to 7.0

12. Upgrade to FP5: CLI0002W Error from stored procedures??


 
Powered by phpBB® Forum Software