Re: pg_upgrade project: high-level design proposal of

On Thu, 30 Sep 2004, Tom Lane wrote:

> Date: Thu, 30 Sep 2004 16:36:02 -0400
>
> "Serguei A. Mokhov" <mokhov(at)cs(dot)concordia(dot)ca> writes:
> > Comments are very welcome, especially _*CONSTRUCTIVE*_...
>
> This is fundamentally wrong, because you are assigning the storage
> manager functionality that it does not have. In particular, the

Maybe, that's why I was asking of all init-db forcing paths, so I can go
level above smgr to upgrade stuff, let say in access/ and other parts. I
did ask that before and never got a reply. So the concept of "Storage
Managers" may and will go well beyond the smgt API. That's the design
refinement stage.

> I don't believe in the idea of incremental "lazy" upgrades very much
> either. It certainly will not work on the system catalogs --- you have
> to convert those in a big-bang fashion,

I never proposed to do that to system catalogs, on the contrary, I said
the system catalogs are to be upgraded upon the postmaster startup. only
user relations are upgraded lazily:

> The relations to be upgraded are ordered according to some priority,
> e.g. system relations being first, then user-owned relations. System
> relations upgrade is forced upon the postmaster startup, and then user
> relations are processed lazily.

So looks like we don't disagree here :)

> The design we'd pretty much all bought into six months ago involved
> being able to do in-place upgrades when the format/contents of user
> relations and indexes is not changing. All you'd have to do is dump and
> restore the schema data (system catalogs) which is a reasonably short
> process even on a large DB, so the big-bang nature of the conversion
> isn't a problem. Admittedly this will not work for every single
> upgrade, but we had agreed that we could schedule upgrades so that the
> majority of releases do not change user data. Historically that's been
> mostly true anyway, even without any deliberate attempt to group
> user-data-changing features together.

Annoyingly enough, they still do change.

> I think the last major discussion about it started here:
> http://archives.postgresql.org/pgsql-hackers/2003-12/msg00379.php
> (I got distracted by other stuff and never did the promised work,
> but I still think the approach is sound.)

I'll go over that discussion and maybe will combine useful ideas together.
I'll open a pgfoundry project to develop it there and then will submit for
evaluation UNLESS you reserved it for yourself, Tom, to fullfill the
promise... If anybody objects the pgfoundry idea to test the concepts,
I'll apply for a project there.

Thank you for the comments!

> regards, tom lane
>

--
Serguei A. Mokhov | /~\ The ASCII
Computer Science Department | \ / Ribbon Campaign
Concordia University | X Against HTML
Montreal, Quebec, Canada | / \ Email!