Tom, > That sounds good, but there are corner cases where it wouldn't work --- > consider a page containing a single maximum-length tuple.
Certainly any mature upgrade-in-place tool will require a "checker" which you run first which determines if you have a prohibitive corner case. Besides, I thought we didn't allow tuples to grow to more than 1/2 page size? Or am I thinking indexes here? > In general I don't see us accepting changes that would increase data > size, but there's at least one troubling exception on the horizon: > per-column or per-value locale support. Another problem is that a strict > rule of "no data size increase ever" might forbid acceptance of changes > that achieve average space savings at the cost of increasing the size of > some lesser-used cases. Our attitude at the meeting was "let's burn that bridge when we come to it". If we can develop a solid in-place upgrade too which will work for 8.1->8.2 and 8.2->8.3, then we've done something worthwhile even if we break it in 8.4 or 8.5. It's possible that we won't implement anything that breaks it for five years or that someone will invent another solution before then, in which case we'd feel pretty dumb for having kept it on the drawing board all that time. Or to put it another way, the page-grows-on-upgrade problem is hard enough that it will probably take as much effort as the whole rest of the upgrade process to solve. So let's tackle one problem at a time. -- Josh Berkus PostgreSQL @ Sun San Francisco ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
