Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> What exactly is the argument for pushing this into 9.3? Since we
>> are past rc1, we should treat that branch as released. If you wouldn't
>> back-patch into all supported branches, you shouldn't be patching 9.3
>> either.
> This is to fix the stats_temp_directory issue that the directory is too
> public. We had agreed that it wasn't a problem before 9.3, but it is in
> that branch because we changed the code to write so many files now
> instead of just one.
To my mind, the new worry about 9.3 was the sloppy file deletion code,
which we've already cleaned up. The remaining argument for tightening
the directory ownership/permissions checking was a security issue: should
we allow a risk that random people could see or alter the stats files.
That's not different in 9.3 than it was before; splitting up the data
into multiple files doesn't seem (to me) to change that risk any.
In fact, I thought that the end of the discussion left us with doubts
about whether we wanted to change this at all. Andres pointed out for
instance that we might need a lock file in the directory to prevent
multiple PG instances from trying to share one temp directory. I don't
know that we need to go that far, but if we don't think we need to defend
against that case, do we need defenses here at all? In the end this is a
"you break it, you get to keep both pieces" issue, with not all that
severe consequences even if the DBA does mess it up. There are other
subdirectories, such as pg_xlog, that we also allow people to relocate,
but for which the consequences of a bad config would be far worse than
they are for the stats dir. We don't go out of our way to prevent
config foulups for other subdirectories, so why this one?
regards, tom lane
