With the stats file split patch 187492b6c2e8cafc5 introduced in 9.3dev, now after a crash the postmaster will try to delete all files in the directory stats_temp_directory. When that is just a subdirectory of PGDATA, this is fine. But it seems rather hostile when it is set to a shared directory, like the popular /dev/shm.
Previously, it would only try to delete the one file /dev/shm/pgstat.stat, so the danger was much smaller.
If /dev/shm is used, this only comes into play when postgres has crashed but the OS has not (If the OS has crashed, /dev/shm it will be empty anyway when it comes back) so perhaps this is not such a large exposure.
The docs don't discuss the issue of what happens if stats_temp_directory is set to a non-private (to PGDATA) directory. The docs also do not explicitly recommend using /dev/shm, but there are plenty of examples of that usage that come up on google (and no examples of using a private subdirectory of /dev/shm rather than /dev/shm itself).
Does this need to be fixed, or at least documented?
Cheers,
Jeff