On 2013-08-19 15:25:38 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > Hm. Is a check like that actually sufficient? The idea of setting > > stats_temp_directory to /dev/shm/postgres or similar in all of several > > clusters on one machine doesn't seem to be that far fetched. > > Hm. We could fairly easily have the lockfile management code also > write a postmaster.pid file into the stats_temp_directory, thus claiming > it in the same way as we do the $PGDATA dir itself. Not sure it's worth > the trouble though, since we've not heard any field reports of this sort > of thing.
The reason I think it's more likely is that pg_stats_directory, to be useful, really needs something like a ramdisk/tmpfs. Which is annoying to create in a persistent fashion... Very likely doing so would cause hard to diagnose planner issues using completely absurd statistics. Not sure how often it would get properly diagnosed. But: > Maybe we're overreacting to this issue for stats_temp_directory, > and tightening up the deletion code is a sufficient fix. You very well might be right. Just wanted to raise the issue. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
