From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
---|---|
To: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com> |
Cc: | Decibel! <decibel(at)decibel(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: Page space reservation (pgupgrade) |
Date: | 2008-11-10 07:52:19 |
Message-ID: | 4917E833.7040409@sun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jonah H. Harris napsal(a):
> On Sun, Nov 9, 2008 at 7:55 PM, Decibel! <decibel(at)decibel(dot)org> wrote:
>> On Nov 8, 2008, at 8:35 PM, Jonah H. Harris wrote:
>>> That's my question. Why is this needed at all?
>> I suspect this is to deal with needing to reserve space in a cluster that
>> you're planning on upgrading to a new version that would take more space,
>> but I think the implementation is probably too simplistic.
>
> Well, if that's what it is, I think it's a fairly poor design
> decision. When I upgrade Oracle, SQL Server, or MySQL, I don't need
> to plan the amount of free space in my blocks a year or more before an
> upgrade. In fact, I don't have to plan it at all... it's completely
> handled by the in-place upgrade.
It will be handled by PostgreSQL as well. The patch is about mechanism and
configuration which will be used by in-place upgrade without any user activity.
Only what user will have to do is run pg_upgrade_prepare() or something like
this and when database will be ready then user can do upgrade.
Zdenek
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2008-11-10 08:05:01 | Re: WIP: Page space reservation (pgupgrade) |
Previous Message | Robert Haas | 2008-11-10 04:28:50 | Re: WIP: Page space reservation (pgupgrade) |