Re: Use of non-restart-safe storage by temp_tablespaces

On Tue, Jun 6, 2017 at 04:39:50AM -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > FWIW, allowing UNLOGGED tables, rather than just TEMPORARY ones,
> > increases the complexity of that project noticeably. For TEMPORARY you
> > basically don't need to do much but to recreate the structure inside the
> > tablespace at start - fairly simple. But for UNLOGGED you need to find
> > a way to recreate the relevant file and init forks - otherwise we might
> > not notice what needs to be reset at a crash restart, and we might error
> > out when executing selects etc. and then the table's not there.
> > Presumably recreating files & init forks that at first table access is
> > doable, but it's not entirely trivial to do locking wise.
>
> I was thinking that you could create the init fork for each unlogged
> table in a permanent tablespace (probably the default one for the
> database).
>
> FWIW I don't think calling these tablespaces "temporary" is the right
> word. It's not the tablespaces that are temporary. Maybe "evanescent".

I was thinking "transient". Amazon uses "ephemeral".

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +