Re: Unable to execute pg_dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joseph Maruca <joseph(dot)maruca(at)masimo(dot)com>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Unable to execute pg_dump
Date: 2020-06-15 05:00:02
Message-ID: 1098936.1592197202@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Joseph Maruca <joseph(dot)maruca(at)masimo(dot)com> writes:
> I end up in the bash-4.1 shell. When executing the following command from within the shell: bash-4.1$ pg_dump db_name > /tmp/my_database.sql I am presented with the following error:

> pg_dump: [archiver (db)] connection to database "db_name" failed: 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.5432"?

Ah, this is a symptom we've seen before. There is disagreement about
where the postmaster ought to put its socket file --- traditionally
PG puts it in /tmp/, but some people feel that's a security hazard and
want to put it in a bespoke directory such as /var/run/postgresql/.

It appears from these symptoms that (a) you are running a server that
puts the socket in /tmp (probably you got that server from a PGDG RPM?)
but (b) you are trying to connect to it using a Red-Hat-provided libpq
(which defaults to expecting the file to be in /var/run/postgresql/).

You have various possible workarounds:

* tell the server to create a socket file in /var/run/postgresql/ too
(see unix_socket_directories);

* tell libpq where to find the socket, e.g. with "psql -h /tmp";

* tell libpq not to use a Unix socket at all, e.g. "psql -h localhost";

* make sure to invoke psql+libpq from the PGDG distribution rather than
using ones supplied by Red Hat.

Generally speaking, mixing PGDG RPMs with vendor-supplied Postgres RPMs
is a recipe for headaches. If you can drop the Red Hat Postgres RPMs
without causing dependency problems, do that. Otherwise, the
two-socket-files solution is probably the best.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Kristjan Mustkivi 2020-06-15 08:51:08 TOAST table size in bytes growing despite working autovacuum
Previous Message David G. Johnston 2020-06-15 04:54:57 Re: Unable to execute pg_dump