Hi,
On Fri, May 1, 2009 at 10:14 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> Well, there's some chance that if the directories don't exist, it's
> because you haven't troubled to mount the correct partitions. And in
> that case just blindly creating the directories will possibly lead to
> a series of unfortunate events.
I understand. Thanks!
> I generally think that it's not a good idea for PG to create
> directories outside $PGDATA. I didn't much like the recent change
> where (AIUI) we follow the symlink and create a directory in the right
> place to be the target thereof. Those kinds of things strike me as
> footguns waiting to go off. If something is not right, I would rather
> have the system complain to me and stop than just do something that
> might not be right. It's easier to fix my init scripts if PG is too
> dumb than to work around PG trying to be too smart.
Yeah, there are trade-offs between the risks and conveniences
of letting postgres create a directory. This issue is related also to
the following patch.
http://archives.postgresql.org//pgsql-hackers/2009-04/msg01057.php
ISTM that there is currently no unified policy of whether to
automatically create the directory specified by an user.
For example, though log_directory is created by postgres,
stats_temp_directory is not. So, I think that we need to consider
that policy to get things going.
IMO, it's not so dangerous that postgres creates the directories,
which doesn't overwrite or remove any existing data. So, I thought
that it's worth writing the patch to create a tablespace directory
in recovery. Is this the right direction? Or, we should completely
forbid the auto-creation of directories outside $PGDATA?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
