From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Mark Dilger <hornschnorter(at)gmail(dot)com> |
Cc: | 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-05-31 14:58:03 |
Message-ID: | 20170531145803.GD812@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
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 | Christoph Berg | 2017-05-31 15:09:40 | Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x |
Previous Message | Robert Haas | 2017-05-31 14:57:49 | Re: POC: Sharing record typmods between backends |