Re: 7.2.3? - Mailing list pgsql-hackers

Tom Lane dijo: 

> Alvaro Herrera <alvherre@atentus.com> writes:
> > Memory leaks and such in the PL modules should be backported also.
> 
> This is getting out of hand :-(

Yes, I agree with you.

> Major back-port efforts just aren't going to happen.  If they did,
> they would significantly impact our ability to work on 7.3 and up;
> does that seem like a good tradeoff to you?

I understand the issue.  I also understand that is very nice for
PostgreSQL to advance very quickly, and requiring backports (and
subsequent slowdown) is not nice at all.  However, for users it's very
important to have the fixes present in newer versions...  _without_ the
burden of having to upgrade!

I agree with Lamar that upgrading is a very difficult process right now.
Requiring huge amounts of disk space and database downtime to do
dump/restore is in some cases too high a price to pay.  So maybe the
upgrading process should be observed instead of wasting time on people
trying to stay behind because of the price of that process.

Maybe there is some way of making the life easier for the upgrader.
Let's see, when you upgrade there are basically two things that change:

a) system catalogs  Going from one version to another requires a number of changes: new  tuples, deleted tuples, new
attributes,deleted attributes.  On-line  transforming syscatalogs for the three first types seems easy.  The  last one
maybe difficult, but it also may not be, I'm not sure.  It  will require a standalone backend for shared relations and
such,but  hey, it's much cheaper than the process that's required now.
 

b) on-disk representation of user data  This is not easy.  Upgrading means changing each filenode from one  version to
another;it requires a tool that understands both (and  more than two) versions.  It also requires a backend that is
ableto  detect that a page is not the version it should, and either abort or  convert it on the fly (this last
possibilityseems very nice).
 
  Note that only tables should be converted: other objects (indexes)  should just be rebuilt.

There are other things that change.  For example, dependencies are new
in 7.3; building them without the explicit schema construction seems
difficult, but it's certainly possible.  The implicit/explicit cast
system is also new, but it doesn't depend on user data (except for user
defined datatypes, and that should be done manually by the user), so
should just be created from scratch.

Is this at least remotely possible to do?

-- 
Alvaro Herrera (<alvherre[a]atentus.com>)
"La fuerza no está en los medios físicos
sino que reside en una voluntad indomable" (Gandhi)