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

Re: postmaster blues after system restart

From: "Thomas F(dot) O'Connell" <tfo(at)sitening(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Cc: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
Subject: Re: postmaster blues after system restart
Date: 2005-10-18 04:17:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Well, after digging a bit deeper, I guess the conclusion is that the  
best practice is to trust package maintainers and follow their lead  
when installing from source.

I notice, for instance, that contrib/start-scripts/linux recommends  
S98 for /etc/rc. That wouldn't've prevented the S99 foul- 
up, but it would've prevented it had been at its  
(apparent) default of S45.

And the problem that bit me looks only to have been an issue when  
used in conjunction with postgres when built from source on Debian,  
as Debian seems to prefer /var/run/postgresql for its socket  
directory, thereby avoiding the issue with /tmp altogether.

So either by following the guidance of contrib/start-scripts/linux or  
the postgresql package for Debian, the problem is alleviated.

But cleaning out /tmp seems to be a part of institutional practice on  
Linux, so it still seems like something about that deserves mention  
somewhere in the postgres documentation since the default for  
unix_socket_directory is /tmp.

Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Open Source Solutions. Optimized Web Development.
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-469-5151 (fax)

On Oct 17, 2005, at 6:36 PM, Thomas F. O'Connell wrote:

> On Fri, 2005-10-14 at 15:49, Thomas F. O'Connell wrote:
>>> The culprit that ended up leading to my original post was an NFS
>>> script that cleans out /tmp. It was running as the last thing in a
>>> given boot level, so it blew away the socket file in /tmp.
>> I'm sure you already know this, but wildly / randomly deleting  
>> things in
>> /tmp is a bad idea...
> Well, here's the story. It was a Debian box, and somehow,  
> wound up at S99 in /etc/rc2.d. I'm not sure how that  
> happened, but it raises some potential questions:
> Converting this to a PostgreSQL on Debian question: is it a good  
> admin practice to go ahead and set TMPTIME=-1 in /etc/default/rcS  
> on Debian servers running postgres?
> If the answer is "yes", then it becomes a more purely Debian  
> question: what are the ramifications of not cleaning out /tmp at  
> boot using initscripts?
> More widely: are there other non-Debian-based distributions that  
> have a similar facility for wiping /tmp at boot? Is changing the  
> timing easy? Is the disabling mechanism the same?
> Maybe not having seen too many prior instances of this particular  
> issue is a good sign that no one is obliterating the contents of / 
> tmp after postgres has started, but the fact that Debian has tools  
> in initscripts that seek to clean out /tmp this makes me think a  
> mention of this in the PostgreSQL documentation might be a good  
> idea (perhaps in 14.6: Post-Installation Setup?).
> But I'd be curious to know the perspective of other Debian/ 
> PostgreSQL admins on where they think the issue really lies or even  
> whether there is a perceived issue.

In response to


pgsql-admin by date

Next:From: Tom LaneDate: 2005-10-18 05:29:31
Subject: Re: postmaster blues after system restart
Previous:From: Tom LaneDate: 2005-10-18 02:37:46
Subject: Re: error: permission denied for schema pg_catalog && pg_temp_nn tables

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