Skip site navigation (1) Skip section navigation (2)

Re: postmaster blues after system restart

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Thomas F(dot) O'Connell" <tfo(at)sitening(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org,Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
Subject: Re: postmaster blues after system restart
Date: 2005-10-18 15:17:40
Message-ID: 1264.1129648660@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-admin
"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 SullivanDate: 2005-10-18 16:13:51
Subject: Re: Solving OID wrap-around in 7.4 DB?
Previous:From: Oliver ElphickDate: 2005-10-18 05:50:49
Subject: Re: postmaster blues after system restart

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group