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

Re: Tom Lane 2017-05-29 <28291(dot)1496087708(at)sss(dot)pgh(dot)pa(dot)us>
> 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.

stats_temp_directory has the same problem. In that case, the risk of
breaking something by calling mkdir() instead of aborting startup
seems pretty low to me.

Christoph