From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Mark Dilger <hornschnorter(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-05-31 13:04:54 |
Message-ID: | 20170531130454.GC812@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmail(dot)com> wrote:
> >> On May 29, 2017, at 11:53 AM, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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 +
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-05-31 13:37:02 | Re: [HACKERS] Channel binding support for SCRAM-SHA-256 |
Previous Message | Beena Emerson | 2017-05-31 12:23:43 | Re: Default Partition for Range |