Gregory Stark píše v pá 30. 01. 2009 v 16:56 +:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Zdenek Kotala wrote:
Bruce Momjian píše v pá 30. 01. 2009 v 10:41 -0500:
Well, I was thinking the new pg_class column would allow the upgrade to
verify the pre-upgrade
Heikki Linnakangas píše v so 31. 01. 2009 v 21:56 +0200:
Robert Haas wrote:
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
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
On Sat, Jan 31, 2009 at 4:21 AM, Simon Riggs si...@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
Simon Riggs escreveu:
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
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
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.
Why was that decision made? Suppose you have a
Robert Haas wrote:
People who upgrade via pg_dump will automatically get the new and
improved widget type because that is what is now called widget. But
people who in-place upgrade will end up with the old_shitty_widget
type. Then you just run some dead simple postupdate script that goes
Robert Haas wrote:
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.
Why was that decision made?
On Jan 31, 2009, at 2:44 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com
wrote:
Robert Haas wrote:
People who upgrade via pg_dump will automatically get the new and
improved widget type because that is what is now called widget. But
people who in-place upgrade will end up with
Heikki Linnakangas wrote:
Bruce Momjian wrote:
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.
Bruce Momjian píše v pá 30. 01. 2009 v 10:41 -0500:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
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
Zdenek Kotala wrote:
Bruce Momjian píše v pá 30. 01. 2009 v 10:41 -0500:
Well, I was thinking the new pg_class column would allow the upgrade to
verify the pre-upgrade script was run properly, but a flat file works
just as well if we assume we are going to pre-upgrade in one pass.
Flat file
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Zdenek Kotala wrote:
Bruce Momjian píše v pá 30. 01. 2009 v 10:41 -0500:
Well, I was thinking the new pg_class column would allow the upgrade to
verify the pre-upgrade script was run properly, but a flat file works
just as well
Heikki Linnakangas wrote:
For example CREATE/ALTER TABLE can cause problems.
Yeah, if the pre-upgrade script determines the amount of reserved space
for each table, and sets it in pg_class or reloptions or whatever, it's
not clear how mwhat to do with tables created after the script is
Bruce Momjian wrote:
Heikki Linnakangas wrote:
For example CREATE/ALTER TABLE can cause problems.
Yeah, if the pre-upgrade script determines the amount of reserved space
for each table, and sets it in pg_class or reloptions or whatever, it's
not clear how mwhat to do with tables created after
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki Linnakangas wrote:
For example CREATE/ALTER TABLE can cause problems.
Yeah, if the pre-upgrade script determines the amount of reserved space
for each table, and sets it in pg_class or reloptions or whatever, it's
not clear how
Gregory Stark st...@enterprisedb.com writes:
Well having a column in pg_class does have some advantages. Like, you could
look at the value from an sql session more easily. And if there are operations
which we know are unsafe -- such as adding columns -- we could clear it from
the server side
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
On Thu, 29 Jan 2009, Bruce Momjian wrote:
One thing I think would help would be a pg_class column that says
whether the table is ready for upgrading.
Some quick reminders here; Tom included that idea from one of your earlier
discussions but also suggested a similar column in pg_database:
Bruce Momjian wrote:
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
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
22 matches
Mail list logo
