Heikki Linnakangas wrote:
> 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.
Yep, makes sense. I had forgotten that idea; sorry.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
