Gregory Stark wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > >> 1) Data does not fit on the new page. It will be solve by pre-upgrade > >> check > >> which reserve space on each page, before upgrade. > > > > Rather than specifying free space as an amount, I was thinking of having > > a boolean like 'ready_for_upgrade' and the system internally would know > > how much free space for each page and tuple. > > I think the original idea was that 8.5 would come with a tool which connected > to an 8.4 database and makes sure things are ok. To do so it has to do two > things: 1) set some server state so that the server doesn't create any new > "bad" pages and 2) check that all the existing pages and fix any "bad" pages. > > The question here is what state does the server need to have to ensure it > doesn't create any new "bad" pages. The simplest option would be a > "minimum_free_space_per_page" guc variable. That would be sufficient if we're > worried about expanding the page header. The user wouldn't have to know about > these, the tool would set it for him. > > If we're worried about expanding tuple header overhead then we would need a > separate option. If we grow any data type representations then we could still > have a problem.
Yes, this is why I was thinking it should just be a boolean and the old server will know the requirements, but it does require us to force a minor upgrade on the old server so it has the proper information embedded in the binary. We could force each page to have the required amount of free space but the binary is going to need to not invalidate that as database processing continues before the upgrade-in-place. -- Bruce Momjian <[EMAIL PROTECTED]> 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
