Robert Haas wrote: > >> The key issue, as I think Heikki identified at the time, is to figure > >> out how you're eventually going to get rid of the old pages. ?He > >> proposed running a pre-upgrade utility on each page to reserve the > >> right amount of free space. > >> > >> http://archives.postgresql.org/pgsql-hackers/2008-11/msg00208.php > > > > Right. ?There were two basic approaches to handling a patch that would > > expand when upgraded to the new version --- either allow the system to > > write the old format, or have a pre-upgrade script that moved tuples so > > there was guaranteed enough free space in every page for the new format. > > I think we agreed that the later was better than the former, and it was > > easy because we don't have any need for that at this time. ?Plus the > > script would not rewrite every page, just certain pages that required > > it. > > While I'm always willing to be proven wrong, I think it's a complete > dead-end to believe that it's going to be easier to reserve space for > page expansion using the upgrade-from version rather than the > upgrade-to version. I am firmly of the belief that the NEW pg version > must be able to operate on an unmodified heap migrated from the OLD pg > version. After this set of patches was rejected, Zdenek actually
Does it need to write the old version, and if it does, it has to carry around the old format structures all over the backend? That was the unclear part. > proposed an alternate patch that would have allowed space reservation, > and it was rejected precisely because there was no clear certainty > that it would solve any hypothetical future problem. True. It was solving a problem we didn't have, yet. -- 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
