Обсуждение: pg_dump cannot connect when executing by a script

Hi all,
I've found in the net a lot of problems similar to mine, but not the solution
for my case: when I executed pg_dump against a database from a script (that
will be executed by cron) I got the following error:

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


and the line the script is executing is the following:

/usr/local/bin/pg_dump -f
/backup/sedeldap/postgresql//webcalendardb2010_05_25.sql -h sedeldapa -U
postgres webcalendardb

and of course, if executed interactively, the above line works. The pg_dump is
for 8.4.0 (installed from freebsd ports).
Moreover, if in the script I add the option -F t than the script complains
that:

pg_dump: too many command-line arguments (first is "webcalendardb")

and of course the following:
/usr/local/bin/pg_dump -F t-f
/backup/sedeldap/postgresql//webcalendardb2010_05_25.sql -h sedeldap -U
postgres webcalendardb

works.

Any idea? The only thing I suspect is that I change the IFS in the shell
script, but I also restore it back before trying to pg_dump.

Luca

In response to Luca Ferrari :
> Hi all,
> I've found in the net a lot of problems similar to mine, but not the solution
> for my case: when I executed pg_dump against a database from a script (that
> will be executed by cron) I got the following error:
>
> pg_dump: [archiver (db)] connection to database "webcalendardb" failed: 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"?

Your unix-scket isn't in /tmp.

Start psql -h localhost and type:

show unix_socket_directory;

This will show you the corrent path to the unix-socket. You can use that
for pg_dump with option -h </path/to/the/socket-dir>


Regards, Andreas
--
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: -> Header)
GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431  2EB0 389D 1DC2 3172 0C99

On Tuesday 25 May 2010 01:13:40 pm A. Kretschmer's cat walking on the keyboard
wrote:
> Your unix-scket isn't in /tmp.
>
> Start psql -h localhost and type:
>
> show unix_socket_directory;
>
> This will show you the corrent path to the unix-socket. You can use that
> for pg_dump with option -h </path/to/the/socket-dir>


Not sure if I get it right: on the machine executing the script postgresql is
not installed, only the client is.
However, it seems to work specifying in the pg_dump the port to which the
script must connect: -p 5432. It is interesting to know why the psql command
is working fine even without such parameter and pg_dump is not.

Luca

Luca Ferrari <fluca1978@infinito.it> writes:
> for my case: when I executed pg_dump against a database from a script (that
> will be executed by cron) I got the following error:

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

> and the line the script is executing is the following:

> /usr/local/bin/pg_dump -f
> /backup/sedeldap/postgresql//webcalendardb2010_05_25.sql -h sedeldapa -U
> postgres webcalendardb

Well, um, that command line can't possibly give rise to that error
message.  pg_dump is evidently trying to connect via Unix socket,
which it absolutely won't do if given a "-h host" argument.

> Any idea? The only thing I suspect is that I change the IFS in the shell
> script, but I also restore it back before trying to pg_dump.

I suspect that the command is being misparsed, perhaps because your
fooling with IFS is having more effect than you realize.  You might want
to try inserting "echo", or some other way of debugging exactly how the
command arguments are getting divided up.

Another theory: the script you're executing is not the one you think it
is.  We've seen more than one person waste a lot of time that way :-(

            regards, tom lane