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
