Re: State of Beta 2

Marc G. Fournier wrote:
>>>And that has nothing to do with user need as a whole, since the care
>>>level I mentioned is predicated by the developer interest level.
>>>While I know, Marc, how the whole project got started (I have read the
>>>first posts), and I appreciate that you, Bruce, Thomas, and Vadim
>>>started the original core team because you were and are users of
>>>PostgreSQL, I sincerely believe that in this instance you are out of
>>>touch with this need of many of today's userbase.

> Huh? I have no disagreement that upgrading is a key feature that we are
> lacking ... but, if there are any *on disk* changes between releases, how
> do you propose 'in place upgrades'?

RTA. It's been hashed, rehashed, and hashed again. I've asked twice if
eRserver can replicate a 7.3 database onto a 7.4 server (or a 7.2 onto a
7.3); that question has yet to be answered. If it can do this, then I
would be a much happier camper. I would be happy for a migration tool
that could read the old format _without_a_running_old_backend_ and
convert it to the new format _without_a_running_backend_. That's always
been my beef, that the new backend is powerless to recover the old data.
OS upgrades where PostgreSQL is part of the OS, FreeBSD ports upgrades
(according to a user report on the lists a few months back), and RPM
upgrades are absolutely horrid at this point. *You* might can stand it;
some cannot.

Granted, if its just changes to the
> system catalogs and such, pg_upgrade should be able to be taught to handle
> it .. I haven't seen anyone step up to do so, and for someone spending so
> much time pushing for an upgrade path, I haven't seen you pony up the time

I believe I pony up quite a bit of time already, Marc. Not as much as
some, by any means, but I am not making one red cent doing what I do for
the project. And one time I was supposed to have gotten paid for a
related project, I didn't. I did get paid by Great Bridge for RPM work
as a one-shot deal, though.

The time I've already spent on this is too much. I've probably put
several hundred hours of my time into this issue in one form or another;
what I don't have time to do is climb the steep slope Tom mentioned
earlier. I actually need to feed my family, and my employer has more
for me to do than something that should have already been done.

> Just curious here ... but, with all the time you've spent pushing for an
> "easy upgrade path", have you looked at the other RDBMSs and how they deal
> with upgrades? I think its going to be a sort of apples-to-oranges thing,
> since I imagine that most of the 'big ones' don't change their disk
> formats anymore ...

I don't use the others; thus I don't care how they do it; only how we do
it. But even MySQL has a better system than we -- they allow you to
migrate table by table, gaining the new features of the new format when
you migrate. Tom and I pretty much reached consensus that the reason we
have a problem with this is the integration of features in the system
catalogs, and the lack of separation between 'system' information in the
catalogs and 'feature' or 'user' information in the catalogs. It's all
in the archives that nobdy seems willing to read over again. Why do we
even have archives if they're not going to be used?

If bugfixes were consistently backported, and support was provided for
older versions running on newer OS's, then this wouldn't be as much of a
problem. But we orphan our code afte one version cycle; 7.0.x is
completely unsupported, for instance, while even 7.2.x is virtually
unsupported. My hat's off to Red Hat for backporting the buffer
overflow fixes to all their supported versions; we certainly wouldn't
have don it. And 7.3.x will be unsupported once we get past 7.4
release, right? So in order to get critical bug fixes, users must
upgrade to a later codebase, and go through the pain of upgrading their
data.

> K, looking back through that it almost sounds like a ramble ... hopefully
> you understand what I'm asking ...

*I* should complain about a ramble? :-)
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
Formerly of WGCR Internet Radio, and the PostgreSQL RPM maintainer since
1999.