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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
