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

From Mark Dilger
Subject Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces
Date
Msg-id F15052D0-5494-4BBC-8D89-121D468C3FEB@gmail.com
Whole thread Raw
In response to Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces
List pgsql-hackers
> On May 31, 2017, at 6:04 AM, Bruce Momjian <bruce@momjian.us> wrote:
>
> 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.

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.

Mark Dilger


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Effect of changing the value for PARALLEL_TUPLE_QUEUE_SIZE
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] POC: Sharing record typmods between backends