Re: [PATCH] Space reservation v02

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 or special table for pg_upgrade will work fine. 

Right, there's no difference in what you can achieve, whether you store 
the additional info in a flat file, special table or extra pg_class 
columns. If you can store something in pg_class, you can store it 
elsewhere just as well.

>> However,  I am afraid requiring this pre-upgrade to run while the server
>> is basically in single-user mode will make upgrade-in-place be a long
>> process for many users, and if it takes a significant time compared to
>> dump/reload, they might as well dump/reload.
> 
> pre_upgrade script should be run during normal operation. There will be
> some limitation.

Right. That's the whole point of having a pre-upgrade script. Otherwise 
you might as well run the conversion in the new version.

> 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.

However, if we have the logic to determine how much space to reserve for 
a table in the backend, as a back-ported patch, then we can invoke it 
for new tables just as well.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com