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