Re: 7.2.3?

From: Alvaro Herrera <alvherre(at)atentus(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)atentus(dot)com>, Justin Clift <justin(at)postgresql(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.2.3?
Date: 2002-09-28 20:42:43
Message-ID: Pine.LNX.4.44.0209281619530.27658-100000@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane dijo:

> Alvaro Herrera <alvherre(at)atentus(dot)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 may be 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 able to
detect that a page is not the version it should, and either abort or
convert it on the fly (this last possibility seems 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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephan Szabo 2002-09-28 20:43:55 Re: 7.2.3?
Previous Message Manfred Koizar 2002-09-28 20:38:43 Re: Bug in PL/pgSQL GET DIAGNOSTICS?