Murthy Nunna <mnunna@fnal.gov> 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