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

From Tom Lane
Subject Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces
Date
Msg-id 28291.1496087708@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces  (Christoph Berg <myon@debian.org>)
Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On May 29, 2017 12:15:37 PM PDT, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>> I think it'd be smart to support the use case directly, because there's
>> interest in it being actually supported (unlike the statu quo).
>> Something like restoring the tablespace to the empty state on boot, if
>> it's known to need it.

> Has the danger of making recovery harder after a restart where somebody forgot to mount some subdirectory ...

Or even worse, the mount happens after PG starts (and creates directories
on the root volume, not knowing they should go onto the mount instead).

I'm too lazy to search the archives right now, but there was some case
years ago where somebody destroyed their database via an ill-thought-out
combination of automatic-initdb-if-$PGDATA-isn't-there and slow mounting.
We'd have to be very sure that any auto-directory-creation behavior didn't
have a potential for that.  Perhaps doing it only for temp tablespaces
alleviates some of the risk, but it still seems pretty scary.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Bug when dumping "empty" operator classes