Re: pg_upgrade project status - Mailing list pgsql-hackers

>> I thought we pretty much had agreement that space reservation was not
>> a good solution to anything, although I admit I'm not quite clear on
>> what alternative was being proposed.
>
> Maybe I miss something, but space reservation was selected as a best
> way. Please, Could you point me related mailing thread?

Hmm, maybe I misrepresented it slightly.  But I did find these:

http://archives.postgresql.org/message-id/49425D07.6030701@enterprisedb.com
http://archives.postgresql.org/message-id/4948D567.4060908@enterprisedb.com

...and just today:
http://archives.postgresql.org/message-id/497F5B7D.90904@enterprisedb.com

...which I think are at least an argument against this patch, if not a
total refutation of the concept of space reservation in general.

Personally, I think you're both barking up the wrong tree.  If the
amount of space that we need to reserve is more complicated than X
bytes per page or per tuple, then your approach will fail.  But it
doesn't have to be a lot more complicated than that before Heikki's
approach of back-patching the space reservation code will fail too.  I
foresee vehement arguments about whether the space reservation code
for feature Y is too complex to back-patch, with the argument going
something like this:

UIP Dude: If we don't back-patch this code, we won't be able to
upgrade-in-place for this release.  That's a huge problem, man!
Conservative Guy: Yeah, but if we do, and we fry somebody's database,
that's a lot worse than not being able to upgrade-in-place.
UIP Dude: I don't think that's going to happen.  This code is pretty solid.
Conservative Guy: You can't prove it doesn't have bugs.

Conservative Guy has a point, but the real issue is that UIP Dude is
making extra work for himself by splitting the work of upgrading the
system between release N and release N+1.  Sure, with enough work, it
will be possible to test the back branch enough to convince yourself
that there are no horrible bugs, and it will also be possible to test
that CVS HEAD can complete the upgrade, but now you have to
exhaustively test TWO releases both independently and for
compatibility with each other.  It's not my project, but I'd rather
walk through fire ants.  I just can't imagine that it will be easier
to change the behavior of the old release to be compatible with what
the new release needs than visca versa.  Even if the new release has
to reshuffle data between pages or stand on its head and wrestle an
epiletic porcupine, I still think it will not be as bad as putting the
space reservation code in the old release and the new page format in
the new release.

...Robert