Murthy Nunna <mnunna@xxxxxxxx> writes: > We downloaded and installed postgres from rpm(s). The installation is on Linux-x64. > We did pg_upgrade of an existing 9.5.3 cluster. > psql -U postgres -d template1 -p 5434 > psql: could not connect to server: No such file or directory > Is the server running locally and accepting > connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5434"? > The socket is in /tmp and that is where it is supposed to be. It looks to me like you have a copy of libpq that was built to think that the default socket location is in /var/run/postgresql not /tmp. That (or some close variant) is a change that many Linux packagers make because they worry that /tmp isn't secure enough. So what seems likely is that even if you are using the copy of psql that came from the PGDG RPMs (a fact you have not proven), it is linking to a libpq.so that came from your Linux distro vendor. "ldd" would help you track down which shared libraries psql is picking up, but I'll bet it's finding libpq.so in /usr/lib or /usr/lib64 rather than wherever the PGDG RPMs installed it. There should be documentation material in the RPMs about how to get psql to find the right libpq. In the extreme you could set LD_LIBRARY_PATH all the time, but there may be an easier way. I've been out of the Linux-packaging game for a little while so I don't remember all the tricks. Another alternative worth considering is to go ahead and make the server create a socket in /var/run/postgresql in addition to /tmp. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
