Bruce Momjian <bruce@momjian.us> 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.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!
