On Fri, Sep 23, 2011 at 10:37 AM, Thom Brown <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers