|
|
Subscribe / Log in / New account

New Features in PostgreSQL 8.0.0

New Features in PostgreSQL 8.0.0

Posted Dec 7, 2004 15:45 UTC (Tue) by emkey (guest, #144)
In reply to: New Features in PostgreSQL 8.0.0 by angdraug
Parent article: PostgreSQL 8.0.0 Release Candidate 1

The backups are beside the point. If you don't have enough disk space then you can't do the conversion.

I agree though that this shouldn't be considered unusual.


to post comments

New Features in PostgreSQL 8.0.0

Posted Dec 7, 2004 18:59 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

you backup (probably as you useually do, possibly by doing a dump instead of backing up the raw disk)

then you wipe out the old database files, upgrade the database engine and restore from your backup

this doesn't require any more disk space then your normal backup/restore requires

I agree that it would be nice if the dump/restore wasn't nessasary, but I don't see it being a critical flaw either

New Features in PostgreSQL 8.0.0

Posted Dec 8, 2004 0:19 UTC (Wed) by khim (subscriber, #9252) [Link] (2 responses)

Your insurance will cover operation disrutions from freak storm when you'll need week to restore your database. It will not cover database engine upgrade. And backup/restore cycle can easily eat few days if we are talking about terabytes.

Oracle and even MySQL can live without such huge move while you are upgrading (true, you need to stop database and make some changes in system tables in both cases but bulk of your data never need to be converted in upgrade process). Yes, this is not the most important problem with PostgreSQL but it's annoying as hell: when you need to sped few days just to switch versions it's not funny - even if you can afford it.

New Features in PostgreSQL 8.0.0

Posted Dec 8, 2004 5:23 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

umm, for MySQL you have completely different table types that you need to start useing with different functionality. this is almost a case of multiple database engines in one program, hardly an easy upgrade path

in addition if you do have terabytes to migrate then use Slony, it lets you replicate between different versions of postgres. once the replication catches up (however long that takes) then you have a single command to run to switch which database you use.

yes this requires multiple database servers to do this, but if you really are running a mission-critical system you should have multiple servers (and at the cost of servers and disk space nowdays it's not that expensive to add it if you need it).

New Features in PostgreSQL 8.0.0

Posted Dec 8, 2004 7:35 UTC (Wed) by sbergman27 (guest, #10767) [Link]

It's more than *almost* a case of multiple database engines in one program.

Straight from the MySQL documentation:

"MySQL supports several storage engines that act as handlers for different table types. MySQL storage engines include both those that handle transaction-safe tables and those that handle non-transaction-safe tables:"


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds