| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> | 
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> | 
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Jerry Sievers <gsievers19(at)comcast(dot)net>, Mark Dilger <hornschnorter(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: Use of non-restart-safe storage by temp_tablespaces | 
| Date: | 2017-06-06 07:39:50 | 
| Message-ID: | 20170606073950.j7ab7ygr4eoodrub@alvherre.pgsql | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2017-06-06 08:17:14 | Fix tab-completion of ALTER SUBSCRIPTION SET PUBLICATION | 
| Previous Message | amul sul | 2017-06-06 07:33:58 | Re: [POC] hash partitioning |