From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Euler Taveira de Oliveira <euler(at)timbira(dot)com> |
Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Space reservation v02 |
Date: | 2009-01-31 15:44:22 |
Message-ID: | 20090131154422.GC8102@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 31, 2009 at 01:28:58PM -0200, Euler Taveira de Oliveira wrote:
> The problem is: how much space do we need at each catalog table? Suppose that
> after 2 releases we need x + 1 bytes per tuple but we only foresaw x bytes; so
> we need to deprecate support for this version and advise DBA to run
> pg_upgrade two times. I prefer a solution where we know beforehand the size
> per tuple so when we're rewriting we could use this information to upgrade.
Just add one column of a variable length type, let pg_upgrade fill it
with the required amount of padding prior to upgrade and you're done.
Ofcourse, the simplest way to me for handling type changes seems to be
to keep the old type OID reserved and have the new version of the type
with a new OID. Then the entire problem vanishes. But it was decided a
long time ago not to do that.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Saito | 2009-01-31 15:44:37 | Re: mingw check hung |
Previous Message | Hiroshi Saito | 2009-01-31 15:39:30 | Re: pgevent warnings on mingw |