Re: [PATCH] Space reservation v02

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Space reservation v02
Date: 2009-01-30 04:57:01
Message-ID: 200901300457.n0U4v1707979@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zdenek Kotala wrote:
>
> I attached second version of space reservation patch. You can see first
> version here:
> http://archives.postgresql.org/pgsql-hackers/2008-12/msg00886.php
>
> I thought about Heikki'es comments and I removed all catalog changes,
> because there are not necessary to be in pg_class. Instead of
> pg_preugrade script should create own schema (pg_upgrade) and tables on
> its needs.
>
> This patch implement settings like relation options. Tom had objection
> about this approach. I can rewrite it and extend pg_class instead.
> However before I will do it I would like to know opinion about rest of
> the patch.
>
> And last thing is most important. Space reservation MUST TO be implemented if we
> want to have 8.4->8.5 upgrade. Else we will be at the begging...

The patch has two space reservations, one per page, another per tuple.
Now, thinking back, what types of changes have we made that increase
storage size. The one that I can think of first is where we made a data
type require larger storage. (I think inet/cidr.) This could not be
handled by this patch because if a row had _two_ values of that type,
there would be no way to specify this using the two supplied parameters.

I think we should try backpatching space reservations routines for a few
releases to see if we need to have these fixed parameters.

One thing I think would help would be a pg_class column that says
whether the table is ready for upgrading. This is something we can't
easily backpatch and would be helpful so people could do their upgrade
preparation in a staged manner, rather than having to do it all at once,
and would give the upgrade scripts confidence that the backpatch had
done everying needed. The backpatched code would set this pg_class
column value when it was done making sure the table is ready for upgrade
(probably via vacuum). I recommend an int2 column to store
PG_VERSION_NUM / 100.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2009-01-30 05:34:17 Re: [PATCH] Space reservation v02
Previous Message Euler Taveira de Oliveira 2009-01-30 02:49:07 Re: reloptions with a "namespace"