Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 4926B64FD3E for ; Mon, 10 Nov 2008 03:52:32 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 97509-08 for ; Mon, 10 Nov 2008 03:52:31 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by mail.postgresql.org (Postfix) with ESMTP id C91E064FD1B for ; Mon, 10 Nov 2008 03:52:27 -0400 (AST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAA7qFDx002113 for ; Mon, 10 Nov 2008 07:52:26 GMT Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KA300801XK3WK00@fe-emea-10.sun.com> (original mail from Zdenek.Kotala@Sun.COM) for pgsql-hackers@postgresql.org; Mon, 10 Nov 2008 07:52:15 +0000 (GMT) Received: from [192.168.1.101] ([89.102.158.6]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA3009AAXUYG5E0@fe-emea-10.sun.com>; Mon, 10 Nov 2008 07:52:10 +0000 (GMT) Date: Mon, 10 Nov 2008 08:52:19 +0100 From: Zdenek Kotala Subject: Re: WIP: Page space reservation (pgupgrade) In-reply-to: <36e682920811091717g65346b45ie02d1cc3a47d3d4a@mail.gmail.com> To: "Jonah H. Harris" Cc: Decibel! , Tom Lane , PostgreSQL-development Message-id: <4917E833.7040409@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <491619D2.2090602@sun.com> <29590.1226192897@sss.pgh.pa.us> <36e682920811081835s5b2b07f1uf849b1d058ff80f5@mail.gmail.com> <36e682920811091717g65346b45ie02d1cc3a47d3d4a@mail.gmail.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) X-Archive-Number: 200811/671 X-Sequence-Number: 127383 Jonah H. Harris napsal(a): > On Sun, Nov 9, 2008 at 7:55 PM, Decibel! 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