Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces
| От | Christoph Berg |
|---|---|
| Тема | Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces |
| Дата | |
| Msg-id | 20170530111024.7lqos3naq5hbqiz2@msg.df7cb.de обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
Re: Tom Lane 2017-05-29 <28291.1496087708@sss.pgh.pa.us> > 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. 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
В списке pgsql-hackers по дате отправления: