Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces
Дата
Msg-id 28291.1496087708@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces  (Andres Freund <andres@anarazel.de>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Bug when dumping "empty" operator classes