Re: WORM and Read Only Tables (v0.1) - Mailing list pgsql-hackers

From Peter Childs
Subject Re: WORM and Read Only Tables (v0.1)
Date
Msg-id a2de01dd0712110607p63128a71s863176235ed1d1a9@mail.gmail.com
Whole thread Raw
In response to WORM and Read Only Tables (v0.1)  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers


On 11/12/2007, Simon Riggs <simon@2ndquadrant.com> wrote:
Attach
------

Writing tables on one system and then moving that data to other systems
is fairly common. If we supported read-only tables then you might
consider how you would publish new versions to people.

For now, we just want to consider how we will upgrade from one release
to another without needing to unload and reload potentially many
Terabytes of data. We can't delete the old data until the new data is
successfully loaded, so we will have a huge temporary storage cost. This
could go very slowly if we use cheaper storage, plus reloading the data
means we have to re-freeze it again also.

So we need a way of attaching the old tables to the new database. We
might call this binary upgrade, or we might be slightly less ambitious
and talk about just moving the old read-only data. That's all I want to
do at this stage.

I'm mentioning this here now to see what comes out in debate, and what
others are planning to work on in this area.


This sounds like allowing new versions to read old versions file structure, Probably I guess on a tablespace by table space basis

Another advantage might be to be able to load an old pitr backup in a new version across major versions. But I'm not sure that would work.

Maybe we need a command to upgrade a tablespace to a new versions file format?

Need to be careful we don't stunt future progress by fixing file format much.

Peter Childs

pgsql-hackers by date:

Previous
From: "Peter Childs"
Date:
Subject: Re: WORM and Read Only Tables (v0.1)
Next
From: Michael Akinde
Date:
Subject: Re: VACUUM ANALYZE out of memory