Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] Space reservation v02

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: 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-30 17:05:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 the script is run. I 
>> guess we need quick scan of pg_class before the actual upgrade to check 
>> that you don't have newly-created tables, and refuse the upgrade if 
>> there is.
> This is where a pg_class column would be useful.  You default the column
> value to -1.  The pre-upgrade script sets the proper reserved space, and
> new tables get a -1 and you check for those just before the upgrade. 

You can do that with a flat file too. If there's any tables in the 
database that were not present when pre-upgrade script was started, 
throw an error.

It might be a bit simpler with a pg_class column, but if we don't know 
what exactly we need to store there, and might need to resort to 
different storage anyway, it doesn't seem worth it.

An extra table as Zdenek suggested in the passing might give the best of 
both worlds. The pre-upgrade script can create it when it's run, so we 
don't need to decide beforehand what columns we need, and it's a table 
so you can query it etc.

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2009-01-30 17:06:53
Subject: Re: [PATCH] Space reservation v02
Previous:From: Fernando IkeDate: 2009-01-30 17:03:57
Subject: [PATCH] Psql List Languages

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group