This turned out to be a wrapper versus binary issue. psql was
running under the wrapper. It ran fine. pg_dump wasn't but when we
corrected this it worked fine too.
This is the first time I've run into this and it's the first time
I've dealt with PostgreSQL on any but a Sparc running Solaris. I
don't know if the same thing happens with Solaris, but I'm going to
investigate just for interest.
Carol
On Apr 29, 2008, at 10:45 AM, Tom Lane wrote:
Carol Walter <walterc@xxxxxxxxxxx> writes:
I'm having a problem that I hope you can help me with. I am getting
the following error when I try to run pg_dumpall.
postgres@machine1:~$ /usr/local/pgsql/bin/pg_dumpall
pg_dumpall: could not connect to database "template1": could not
connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
If I run the command "psql template1", I can connect to template1
just fine.
Does "which psql" say that you're using the psql in
/usr/local/pgsql/bin?
It sounds to me a bit like you have two sets of PG programs with
different default port numbers compiled into them. Which port is
the server actually listening on?
This is a new installation of postgresql 8.3 on a Debian Linux
machine.
Debian is a rather nasty environment for custom-built PG
installations,
because they have their own ideas of where to put the PG programs
and what port numbers they should run on. I'm thinking you are
connecting to a Debian-supplied postmaster on a non-standard port,
and not to your own installation at all.
regards, tom lane
