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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
