Re: pg_dump (PostgreSQL) 9.4.1 - delay in checking if file exists

On Tue, Jul 7, 2015 at 4:26 AM, pinker <pinker(at)onet(dot)eu> wrote:

> I made mistake in a filename in pg_dump command, i.e. have used path from
> another server, which not exists on this one. pg_dump instead of checking
> permissions / existence of output file first dumped the whole database and
> at the end (after some time ... ) threw an error:
>
> (...)
> pg_dump: saving database definition
> pg_dump: [archiver] could not open output file
> "/home/.../dum-...._20150707_1059.sql": No such file or directory
>
> Is it correct behavior? Why wasting so much time and resources leaving
> checking the output file at the last moment?
>
>
​What version of PostgreSQL? What OS? What was the command line? On Linux
x86_64, Fedora 22​, PostgreSQL version 9.4.4, I did:

pg_dump -f /junk/x tsh009

and, almost immediately, got back:

pg_dump: [archiver] could not open output file "/junk/x": No such file or
directory

I even looked at the source to pg_dump (not that I'm a good C developer!)
and it appears to me that it basically parses the options, opens the output
file, then connects to the database server.

--

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown