Re: Tom Lane 2017-05-29 <28291.1496087...@sss.pgh.pa.us> > Andres Freund <and...@anarazel.de> writes: > > On May 29, 2017 12:15:37 PM PDT, Alvaro Herrera <alvhe...@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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
