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@indiana.edu> 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
