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