"Thomas F. O'Connell" <tfo(at)sitening(dot)com> 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
In response to
pgsql-admin by date
|Next:||From: Andrew Sullivan||Date: 2005-10-18 16:13:51|
|Subject: Re: Solving OID wrap-around in 7.4 DB?|
|Previous:||From: Oliver Elphick||Date: 2005-10-18 05:50:49|
|Subject: Re: postmaster blues after system restart|