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  <br...@momjian.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 +

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to