"Thomas F. O'Connell" <tfo@xxxxxxxxxxxx> writes: > Does postgres just use /tmp because it will generally be known to > exist and be writable? I suppose that was the original motivation. We've had repeated troubles over the years with using /tmp --- for example, the code now goes to considerable lengths to update the socket's timestamp periodically so that it won't be seen as a target by scripts that clean out /tmp entries more than X minutes old. It's really not very feasible to change the standard default, though, because that would break too many clients (it's not very different from changing the default port number). There's also the small problem that there is no good alternative choice; there is no other fixed directory path that can be assumed writable by a non-privileged postmaster on every Unix. So I'm afraid we're stuck with /tmp as the default socket location. In any case, I don't think there's much doubt that unconditionally cleaning out /tmp *after* beginning to start daemons is simply broken. That script has no excuse whatever for thinking that there can't be some other process actually using /tmp at the time it's running. If you're going to have a forcible cleanout of /tmp during reboot, it has to happen before the /etc/rc.d scripts begin to run. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match