Upgrading a database dump/restore - Mailing list pgsql-hackers

From Mark Woodward
Subject Upgrading a database dump/restore
Date
Msg-id 18000.24.91.171.78.1160077578.squirrel@mail.mohawksoft.com
Whole thread Raw
Responses Re: Upgrading a database dump/restore  (Andrew Dunstan <andrew@dunslane.net>)
Re: Upgrading a database dump/restore  (AgentM <agentm@themactionfaction.com>)
Re: Upgrading a database dump/restore  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Not to cause any arguments, but this is sort a standard discussion that
gets brought up periodically and I was wondering if there has been any
"softening" of the attitudes against an "in place" upgrade, or movement to
not having to dump and restore for upgrades.

I am aware that this is a difficult problem and I understand that if there
is a radical restructuring of the database then a dump/restore is
justified, but wouldn't it be a laudable goal to *not* require this with
each new release?

Can't we use some release as a standard who's binary format "shall not be
changed." I know the arguments about "predicting the future," and all, but
standards and stability are important too. I'm not saying it should never
ever change or never ever require a dump/restore, but make it, as policy,
difficult to get past the group and the norm not to require d/r.

The issue is that as disks get bigger and bigger, databases get bigger and
bigger, and this process becomes more and more onerous. If you haven't
noticed, data transmission speeds are not accelerating at the rate disk
space is growing.

I am currently building a project that will have a huge number of records,
1/2tb of data. I can't see how I would ever be able to upgrade PostgreSQL
on this system.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Storing MemoryContext Pointers
Next
From: Andrew Dunstan
Date:
Subject: Re: Upgrading a database dump/restore