On Sat, Jan 31, 2009 at 4:21 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Tue, 2009-01-27 at 13:06 +0100, Zdenek Kotala wrote:
>> Space reservation MUST TO be implemented if we
>> want to have 8.4->8.5 upgrade.
>
> Why not just add a few dummy columns onto each catalog table? If we need
> space to expand a row we can just drop one of the dummy columns from the
> new catalog definition.
>
> That's an old DBA trick to avoid having to rewrite a table when you want
> to add a column.
>
> Seems much simpler to add columns than write special code, especially
> when we might find the new code has bugs and hasn't done what we thought
> it might.
Wow, that is really sneaky. I like it!
Actually, this even handles cases that the patch won't. For example,
suppose there's an ARRAY[] of 2-byte objects and in PG 8.5 we make all
of them 4 bytes. A fixed amount of space reservation per tuple is
useless, but your idea works fine. Just add a new column of the same
type and set them equal. As long as you can roughly predict how much
extra crap to stuff in there, you're good.
Can some variant of this be made to work if the index tuples expand?
What if we're expanding the page header?
Even if it can, space reservation (whether through adding dummy
columns or an explicit facility) seems like an effort to avoid the
hard problems of moving stuff around between pages during the upgrade
process itself. I'm not sure that any such effort can be 100%
successful, but then again if we don't need any special code changes
to support it, maybe that doesn't matter right now.
...Robert
