Gregory Stark wrote:
> 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.
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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
