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". Also, do we really need it to be a keyword after CREATE? We could put the option in the WITH clause of CREATE TABLESPACE instead. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
