Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.10.1/8.10.1) with ESMTP id e7J5Ztm22119 for ; Sat, 19 Aug 2000 01:35:55 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id BAA22272; Sat, 19 Aug 2000 01:35:47 -0400 (EDT) To: "Jim O'Rourke" cc: "'pgsql-interfaces@postgresql.org'" Subject: Re: /tmp/.s.PGSQL.${PGPORT} In-reply-to: <614E0D291FEAD311BD370050DA76B9D0041A2A@EXCHSERV> References: <614E0D291FEAD311BD370050DA76B9D0041A2A@EXCHSERV> Comments: In-reply-to "Jim O'Rourke" message dated "Fri, 18 Aug 2000 10:58:51 -0400" Date: Sat, 19 Aug 2000 01:35:47 -0400 Message-ID: <22269.966663347@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200008/115 "Jim O'Rourke" writes: > Is anybody else having problems with the /tmp/.s.PGSQL.${PGPORT} file being > removed by “cleantmp” et al. > /tmp is a dumping ground that rightly gets cleaned out periodically. /tmp is a damfool place to have put the socket file, no doubt about that. But we are stuck with it now if we don't want to break existing applications --- the location of the socket file is a critical hardwired part of the wire-level protocol, since the client and server MUST both know it *before* any communication happens. This was argued back around 6.4, IIRC, and we decided to do nothing. The argument in favor of doing nothing seems even stronger now, with a couple more years worth of existing clients out there... Solutions: 1. Tweak your tmp-cleaning cron job to not remove the socket file. 2. Use IP instead of Unix-socket connections, so that your clients don't care whether the socket file is there or not. regards, tom lane