On Fri, Sep 23, 2011 at 10:37 AM, Thom Brown <thom@linux.com> wrote:
> Couldn't this come under tablespace changes then? After all the
> use-case stated would require a separate tablespace, and you could do
> something like:
>
> CREATE VOLATILE TABLESPACE drive_made_of_wax_left_in_the_sun LOCATION
> '/mnt/ramdisk';
>
> All objects then created or reassigned therein would <insert magic
> stuff here>. In theory it would be independent of UNLOGGEDness, but I
> can see this would be problematic because such tables wouldn't be
> allowed foreign key references to tables within a stable tablespace
> and vice-versa, since the wonky tablespace could collapse any minute
> and integrity with it.
I don't get it. It would certainly be possible to create a VOLATILE
TABLESPACE in which only TEMPORARY tables could be created. We would
just disallow the creation of anything other than a temporary table
within that tablespace, and if the contents of the tablespace get
wiped out, WDC. (Mind you, I think we'd likely want to insist that
the pg-version directory manufactured by CREATE TABLESPACE would stick
around... or else we'd need some provision for recreating it on every
startup.)
However, if you want a VOLATILE TABLESPACE to allow not only TEMPORARY
but also UNLOGGED objects, it's not so simple, because the _init forks
of an unlogged relation are not disposable. Those are not allowed to
disappear, or you're going to be in trouble. So the issue still comes
down to this: where are we gonna put those _init forks? I guess we
could do something like this:
CREATE TABLESPACE now_you_see_me_now_you_dont LOCATION
'/mnt/highly_reliable_san' VOLATILE LOCATION '/mnt/ramdisk';
All forks of temporary relations, and all non-_init forks of
non-temporary relations, could be stored in the VOLATILE LOCATION,
while everything else could be stored in the regular LOCATION.
Hmm... actually, I kind of like that. Thoughts?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company