Re: [HACKERS] Upgrading a database dump/restore

[AgentM]

On Oct 5, 2006, at 15:46 , Mark Woodward wrote:
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.

Indeed. The main issue for me is that the dumping and replication  
setups require at least 2x the space of one db. That's 2x the  
hardware which equals 2x $$$. If there were some tool which modified  
the storage while postgres is down, that would save lots of people  
lots of money.

-M

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly