> On May 31, 2017, at 7:58 AM, Bruce Momjian <br...@momjian.us> wrote: > > On Wed, May 31, 2017 at 07:53:22AM -0700, Mark Dilger wrote: >>> Just to clarify, the TEMPORARY clause would allow the tablespace to >>> start up empty, while normal tablespaces can't do that, right? One big >>> problem is that we don't have any way to prevent non-temporary >>> tablespaces from being created on transient storage. I wonder if we >>> should document this restriction, but it seems awkward to do. >> >> It depends what you mean by allowing the tablespace to start up empty. >> It must not be empty once users can run queries, since the catalogs will >> still >> have entries for the tablespace and its dependent objects. So, what must >> happen is that during startup the tablespace and its temporary tables and >> indexes get recreated if they are missing. > > Uh, I thought only the sessions that created the temporary objects could > see them, and since they are not in WAL and autovacuum can't see them, > their non-existence in a temporary tablespace would not be a problem.
You are correct. I was thinking about an extension to allow unlogged tablespaces on temporary filesystems, but got the words "unlogged" and "temporary" mixed up in my thinking and in what I wrote. I should have written that unlogged tablespaces would only host unlogged tables and unlogged indexes, such that users are not surprised to find their data missing. On reflection, I think both features are worthwhile, and not at all exclusive of each other, though unlogged tablespaces is probably considerably more work to implement. Mark Dilger -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers