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: http://www.postgresql.org/mailpref/pgsql-hackers
