Thread: 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