Recently updated my machine from Mac OS X Lion (10.7.4) to Mountain Lion (10.8) and I think it borked my PostgreSQL installation. It was installed originally via Homebrew. I'm not a DBA, but hoping someone can tell me how to troubleshoot this.

I am unable to connect (but was able to before pre-Mountain Lion):

$ psql -U rails -d myapp_development
psql: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/var/pgsql_socket/.s.PGSQL.5432"?

But Postgres is still clearly running:

$ ps aux | grep postgres
meltemi          2010   0.0  0.0  2444124   5292   ??  Ss   Wed01PM   0:00.02 postgres: rails myapp_development [local] idle    
meltemi           562   0.0  0.0  2439312    592   ??  Ss   Wed12PM   0:02.28 postgres: stats collector process       
meltemi           561   0.0  0.0  2443228   1832   ??  Ss   Wed12PM   0:01.57 postgres: autovacuum launcher process       
meltemi           560   0.0  0.0  2443096    596   ??  Ss   Wed12PM   0:02.89 postgres: wal writer process       
meltemi           559   0.0  0.0  2443096   1072   ??  Ss   Wed12PM   0:04.01 postgres: writer process       
meltemi           466   0.0  0.0  2443096   3728   ??  S    Wed12PM   0:00.85 /usr/local/bin/postgres -D /usr/local/varpostgres -r /usr/local/var/postgres/server.log

And it's responding to queries (both to a test db and the development db) from a local Rails app

  User Load (0.2ms)  SELECT "users".* FROM "users" 
  Rendered users/index.html.haml within layouts/application (1.3ms)

There appears to be no /var/pgsql_socket/ directory, let alone the /var/pgsql_socket/.s.PGSQL.5432 socket file mentioned above!?! Maybe the install of Mountain Lion wiped that out?

$ ls -l /var/ | grep pg
drwxr-x---   2 _postgres  _postgres    68 Jun 20 16:39 pgsql_socket_alt

How can I troubleshoot this?

  • Not a postgres admin, but a missing socket file sounds about right. Create the /var/pgsql_socket directory (with your user having write permissions) and restart the server. See if that fixes it Commented Jul 26, 2012 at 20:54
  • Related question on SO. Seems like Apple didn't do a great job with the upgrade. Commented Jul 26, 2012 at 20:57
  • is there any mention of a socket file being created in the log file /usr/local/var/postgres/server.log ?
    – Philᵀᴹ
    Commented Jul 26, 2012 at 21:55
  • @ErwinBrandstetter How do you expect Apple to do a "good job" of upgrading manually installed 3rd party *nix apps?
    – Philᵀᴹ
    Commented Jul 26, 2012 at 21:55
  • @Phil- no mention. I'm starting to think this might be a path variable problem. I think my $PATH got changed with the upgrade /usr/bin is ahead of /usr/local/bin and I think Mountain Lion may come with PostgreSQL pre-installed!?! Investigating...
    – Meltemi
    Commented Jul 26, 2012 at 22:00

14 Answers 14


I found that I had an extremely similar problem, namely that postgres was opening a socket in /var/pgsql_socket_alt where none of my software expects to look, but the solution to my problem was not only a problem with my $PATH.

I had to create the directory /var/pgsql_socket, chown it to myself, and set unix_socket_directory in postgresql.conf (located in /usr/local/var/postgres) to that directory, then use the pg_ctl binary in /usr/local/bin to start the right postgres server successfully (which is where $PATH comes in – make sure which pg_ctl resolves to /usr/local/bin/pg_ctl, or just always call it explicitly).

This might help other users who find this question via the /var/pgsql_socket_alt mention.

  • Interesting. Are you also on Mountain Lion? Did you install PostgreSQL with Homebrew? If so, wonder if anyone else can verify this solution as opposed to changing my $PATH as I have done.
    – Meltemi
    Commented Jul 26, 2012 at 23:42
  • Yes, yes, and I hope so!
    – Will
    Commented Jul 27, 2012 at 2:47
  • @wolftron your solution was bang-on for me (Mountain Lion, homebrew/postgres, /var/pgsql_socket_alt, the whole nine). Is this a new issue on Mountain Lion with homebrew? I'll open a ticket with them if you think so.
    – user10458
    Commented Jul 27, 2012 at 17:21
  • Looks like we've got verification from @Jamie.
    – Will
    Commented Jul 30, 2012 at 3:24
  • I can confirm this problem and the solution on OS X 10.8.2 / brew installation of postgresql 9.2.1.
    – Hartwig
    Commented Feb 13, 2013 at 9:27

A plausible and typical explanation would be that the psql that comes with homebrew is in /usr/local/bin/psql which is different from the one that would be in your $PATH, like /usr/bin/psql (bundled with OS X). You may want to try with the full path:

$ /usr/local/bin/psql -U rails -d myapp_development

Also, there's something rather unusual in the ps output of your question: the postgres server is running under a meltemi Unix user, whereas generally, the dedicated postgres Unix user is used for that.

  • Also, _postgres (with underscore) for user / group are unknown to me. Is that an artifact or expected? Commented Jul 26, 2012 at 22:10
  • Yes, it appears to be a $PATH problem as you stated. Things work as before when I use /usr/local/bin/psql to access the database. Either Lion didn't have a system PostgreSQL or my $PATH was set up differently. It's been a year since I last muddled with this so I can't remember exactly. As for the Unix user...with a Homebrew install of PostgreSQL the server is launched by launchd and the user is set to the local user who installed it, as a default. Things are set up differently on Mac OS X Server which starts up PostgreSQL automatically under postgres.
    – Meltemi
    Commented Jul 26, 2012 at 22:10


psql -U rails -d myapp_development -h localhost


psql -U rails -d myapp_development -h

I don't know of any config file for the psql client. However psql does respect a number of environment variables that correlate to command line options.

So to have the psql automatically use the socket of your choice you can set the PGHOST variable to the directory containing the socket. i.e.

psql -d mydatabsase
  • 1
    It's not documented anywhere I can find that you can set PGHOST to the directory where the socket files live. But that does in fact work. Thanks! Commented Jun 5, 2017 at 20:53

Late, but I found this helpful: http://tammersaleh.com/posts/installing-postgresql-for-rails-3-1-on-lion

That was for Lion, but I was having same issues as the one in this thread after upgrading from 10.6.8 to Mountain Lion and having installed PostgreSQL via HomeBrew prior while on 10.6.8. I also had the mysterious /var/pgsql_socket_alt folder post-upgrade, but I just removed it and created /var/pgsql_socket as suggested by @wolftron. However, that wasn't the final solution.

If I left unix_socket_directory blank/commented out in postgresql.conf, any projects existing prior to the upgrade would complain that the socket in /var/pgsql_socket was missing. But if I changed conf and hard-coded var/pgsql_socket, any new projects would complain that the socket in /tmp was missing. Very frustrating...until I re-installed pg gem in an pre-10.8 project (gem uninstall pg && gem install pg) and left unix_socket_directory commented out in conf file. After a quick pg_ctl to restart the server, both new and old projects worked. My pgsql socket lives in /tmp now, fwiw.

Sidenote: if you are using activerecord-postgresql-adapter gem, uninstall it first, then re-install pg, then install activerecord-postgresql-adapter again.


I've only just signed up to the dba SE, so don't seem to be able to comment on the relevant post (what a crock!).

However, I was confident that I was in the same boat as @thure. I'd made sure /usr/local/bin was earlier in my PATH than /usr/bin, had checked which binaries the shell had hashed with which and type, etc.

I saw the same symptoms as @thure. Then I had an epiphany; I realised I'd rebuilt the pg gem (I'm using Ruby) in a shell whose PATH had been adversely affected by Mac's path_helper (which is run from /etc/profile and puts /usr/bin before /usr/local/bin).

I uninstalled pg and reinstalled it in a shell whose PATH was correct. All of a sudden I could connect!

So make sure you recompile your language bindings people, and let them find the correct copy of (presumably) pg_config.


I can't quickly find the link where I found this nugget, but it worked for me.

export PGHOST=localhost

Oh, here's the link. https://stackoverflow.com/questions/13868730/socket-file-var-pgsql-socket-s-pgsql-5432-missing-in-mountain-lion-os-x-ser


I found this answer: https://stackoverflow.com/questions/10763143/in-rails-couldnt-create-database-for-adapter-postgresql And, as simple as it was, it worked for me... ran a $bundle update and it started working again.


I found that symlinking the actual location to the expected location worked just fine:

sudo ln -s /var/pgsql_socket_alt /var/pgsql_socket

along the lines of the accepted answer by @thure but simpler.


Here it is, 2016, El Capitan is out there, and Apple keeps changing things up. Postgres is installed as part of the OS, and the postgres config file sets the unix_socket_directories property in postgresql.conf to /tmp. The socket is in /tmp/.s.PGSQL.5432. I was able to get around the problem by executing the following:

sudo ln -s /tmp /var/pgsql_socket

Hope this helps someone.


Look for the correct socket file

find / -name .s.PGSQL.5432 -ls

From the result get the path to the file and use the path with the "-h" parameter within the psql command

For example, this is the way I connect to the macOS Server Calendar and Contacts database (within a ssh session to the server):

sudo psql -U _calendar -h /private/var/run/caldavd/PostgresSocket/ -d caldav

Then, the socket file at the path would be used to connect.


By default postgres seems to be trying to connect via unix-domain-sockets. UNIX DOMAIN SOCKET

This happened to me when I was running postgres instance on docker. You have to see what kind of connection is your server accepting. For me it was clearly TCP and not unix domain socket.

Adding flag to accept host redirected the connection to correct path and fixed the issue.

psql -U username -p port -h host

PS: Unix domain sockets work on kernel level and the connection doesn't have to go through all the jazz required for TCP connections. They are pretty fast and efficient when you want to make connection to your own machine from a different process as a part of Interprocess Communication.


Hello world :)
The best but strange way for me was to do next things.

1) Download postgres93.app or other version. Add this app into /Applications/ folder.

2) Add a row (command) into the file .bash_profile (which is in my home directory):

export PATH=/Applications/Postgres93.app/Contents/MacOS/bin/:$PATH
It's a PATH to psql from Postgres93.app. The row (command) runs every time console is started.

3) Launch Postgres93.app from /Applications/ folder. It starts a local server (port is "5432" and host is "localhost").

4) After all of this manipulations I was glad to run $ createuser -SRDP user_name and other commands and to see that it worked! Postgres93.app can be made to run every time your system starts.

5) Also if you wanna see your databases graphically you should install PG Commander.app. It's good way to see your postgres DB as pretty data-tables

Of, course, it's helpful only for local server. I will be glad if this instructions help others who has faced with this problem.


I got this same error from trying to run psql on the command line. It turned out that my solution was far simpler. I had mis-configured the listening port in the config file: /etc/postgresql/9.4/main/postgres.conf. I had changed the port from port = 5432 to port = 5433. When I changed it back to 5432, it worked as expected.

To test if you have done something similar, you can run $ psql -p5433 There are a number of useful options like this for the psql command that you can find here: http://www.postgresql.org/docs/9.4/static/app-psql.html so that you can test out your OWN particular misconfiguration. Of course, you can simply remove your last set of config changes from the *.conf files, too, to test if those are the source of your problem. I think it is certainly worth checking out before you muck about with file permissions and ownerships. (Just don't forget to /etc/init.d/postgresql restart )

What I could NOT find was the config file that sets the default values for the psql CLI command. Can someone comment with that, please?

For me I always go back to my first principle of programming: "I am usually the source of any given error!"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.