Re: Use of non-restart-safe storage by temp_tablespaces

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: Use of non-restart-safe storage by temp_tablespaces
Date: 2017-05-29 19:55:08
Message-ID: 28291.1496087708@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On May 29, 2017 12:15:37 PM PDT, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniele Varrazzo 2017-05-29 20:38:18 [PATCH] Fixed malformed error message on malformed SCRAM message.
Previous Message Tom Lane 2017-05-29 19:45:11 Re: [PATCH] relocation truncated to fit: citus build failure on s390x