Thread: /tmp/.s.PGSQL.${PGPORT}

/tmp/.s.PGSQL.${PGPORT}

From
"Jim O'Rourke"
Date:
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.

The only workaround I’ve come up with is to kill and restart the postmaster
when a connection attempt fails.  This works fine except when the admin
wants the server down, ie: maintenance.

Any other suggestions would be appreciated !!

Thanks

Jim O’Rourke


Re: /tmp/.s.PGSQL.${PGPORT}

From
Tom Lane
Date:
"Jim O'Rourke" <JimO@Routescape.com> 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