Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces
Date
Msg-id 20170531130454.GC812@momjian.us
Whole thread Raw
In response to Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces  (Mark Dilger <hornschnorter@gmail.com>)
List pgsql-hackers
On Wed, May 31, 2017 at 07:53:53AM -0400, Robert Haas wrote:
> On Tue, May 30, 2017 at 6:50 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
> >> On May 29, 2017, at 11:53 AM, Bruce Momjian <bruce@momjian.us> wrote:
> >> Right now we don't document that temp_tablespaces can use
> >> non-restart-safe storage, e.g. /tmp, ramdisks.  Would this be safe?
> >> Should we document this?
> >
> > The only safe way to do temporary tablespaces that I have found is to extend
> > the grammar to allow CREATE TEMPORARY TABLESPACE, and then refuse
> > to allow the creation of any non-temporary table (or index on same) in that
> > tablespace.  Otherwise, it is too easy to be surprised to discover that your
> > table contents have gone missing.
> 
> I think this would be a sensible approach.

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.

--  Bruce Momjian  <bruce@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 +



pgsql-hackers by date:

Previous
From: Beena Emerson
Date:
Subject: Re: [HACKERS] Default Partition for Range
Next
From: Robert Haas
Date:
Subject: Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256