I posted a note to the hackers list about this very issue last week.  It was
never responded to.  I am prepared to do the work and submit a patch, but I
wanted some input on how best to do it.  We had a problem with a backup
script silently failing when the disk was full.  I guess I will get started
on it and will get feedback on the patch when it's submitted.

Matt

> -----Original Message-----
> From:	Anand Raman [SMTP:araman@india-today.com]
> Sent:	Thursday, January 04, 2001 4:12 AM
> To:	postgresql
> Subject:	[GENERAL] pg_dump return status..
> 
> hi guys
> 
> I am trying to create a shell script which dumps my db to a flat file ..
> 
> To dump the database i use the pg_dump command..
> 
> I find that irrespective of the fact whether pg_dump managed to connect
> to the db or not the return status ($?) is always zero.. This throws the
> shell script in a spin which continues even when pg_dump is not able to
> connect ..
> 
> Is there anyway around this. I thought of one way was to check stderr
> for the occurence of the word "failed" and then exit..
> 
> Ur suggestions are most welcome
> 
> version postgresql 702 
> 
> Regards
> Anand Raman
> 

Thu, 4 Jan 2001 19:14:59 -0600 
Matthew <matt@ctlno.com>
RE: pg_dump return status..
At 19:14 4/01/01 -0600, Matthew wrote:
>I posted a note to the hackers list about this very issue last week.  It was
>never responded to.  I am prepared to do the work and submit a patch, but I
>wanted some input on how best to do it.  We had a problem with a backup
>script silently failing when the disk was full.  I guess I will get started
>on it and will get feedback on the patch when it's submitted.

7.0.2 and CVS seem to set $? for me...at least when I try to dump a
nonexistant DB, dump to a nonexistant location or dump to an area I have no
privs for. Also, the code looks like it does an exit(1) whenever there is
an error. Is there a Unix/C/shell interaction that's not working for you?


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Fri, 05 Jan 2001 12:40:13 +1100
Philip Warner <pjw@rhyme.com.au>
Re: [HACKERS] RE: pg_dump return status..
Matthew <matt@ctlno.com> writes:
> I posted a note to the hackers list about this very issue last week.  It was
> never responded to.  I am prepared to do the work and submit a patch, but I
> wanted some input on how best to do it.  We had a problem with a backup
> script silently failing when the disk was full.

Talk to Philip Warner about detecting output write failures.  I think
this might be a lot easier in current sources than it would have been in
7.0.* or before; the actual I/O is more centralized, and I think you
could reasonably hope to check for write errors at just a couple of
places.  But I'm not sure where the best places are.

>> I find that irrespective of the fact whether pg_dump managed to connect
>> to the db or not the return status ($?) is always zero.

I think this is probably some sort of mistake in your script.  pg_dump
certainly returns a nonzero exit status for any failure that it detects,
at least in all the versions I've used.  Matthew's correct that it
doesn't detect write failure on its output file, but that's not the
case you're claiming...

			regards, tom lane

Thu, 04 Jan 2001 20:50:09 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump return status.. 
At 20:50 4/01/01 -0500, Tom Lane wrote:
>
>Talk to Philip Warner about detecting output write failures.  I think
>this might be a lot easier in current sources than it would have been in
>7.0.* or before; the actual I/O is more centralized, and I think you
>could reasonably hope to check for write errors at just a couple of
>places.

There are a few places to check, but a lot less than before. Assuming I
should just die on any failed write (which seems reasonable), how do I
check for a failed write in a way that works on all Unixes? Is the
following OK:

- fwrite: ok if return value equals item count
- fprintf: ok if return value > 0.
- fputc: ok if != EOF


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Sat, 06 Jan 2001 00:25:13 +1100
Philip Warner <pjw@rhyme.com.au>
Re: [HACKERS] Re: pg_dump return status.. 
Philip Warner <pjw@rhyme.com.au> writes:
> There are a few places to check, but a lot less than before. Assuming I
> should just die on any failed write (which seems reasonable),

Yes, I see no point in continuing after a write failure.  Just print
the strerror() message and exit.

> how do I
> check for a failed write in a way that works on all Unixes? Is the
> following OK:

> - fwrite: ok if return value equals item count
> - fprintf: ok if return value > 0.
> - fputc: ok if != EOF

Probably fprintf() >= 0 --- according to my specs, it returns the number
of chars emitted, or a negative value on error.  The other two are
correct.

Don't forget to check for a successful fclose() too, since otherwise
you won't notice a failure in dumping the last bufferload of data.

I do not recall the success/failure return codes for the zlib calls,
but I assume they check for write failure and reflect it back ...

			regards, tom lane

Fri, 05 Jan 2001 11:20:43 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: pg_dump return status.. 
On Fri, Jan 05, 2001 at 11:20:43AM -0500, Tom Lane wrote:
> Philip Warner <pjw@rhyme.com.au> writes:
> > how do I
> > check for a failed write in a way that works on all Unixes? Is the
> > following OK:
> 
> > - fwrite: ok if return value equals item count
> > - fprintf: ok if return value > 0.
> > - fputc: ok if != EOF
> 
> Probably fprintf() >= 0 --- according to my specs, it returns the number
> of chars emitted, or a negative value on error.  The other two are
> correct.

An fprintf returning 0 is a suspicious event; it's easy to imagine 
cases where it makes sense, but I don't think I have ever coded one.
Probably >N (where N is the smallest reasonable output, defaulting 
to 1) may be a better test in real code.

As I recall, on SunOS 4 the printf()s don't return the number of 
characters written.  I don't recall what they do instead, and have
no access to such machines any more.

Other old BSD-derived systems are likely to have have wonky return 
values/types on the printf()s.  Looking at the list of supported 
platforms, none jump out as likely candidates, but in the "unsupported" 
list, Ultrix and NextStep do.  (Do we care?)

If SunOS 4 is to remain a supported platform, the printf checks may 
need to be special-cased for it.

Nathan Myers
ncm@zembu.com

Fri, 5 Jan 2001 14:17:09 -0800
ncm@zembu.com (Nathan Myers)
Re: pg_dump return status..
ncm@zembu.com (Nathan Myers) writes:

> An fprintf returning 0 is a suspicious event; it's easy to imagine 
> cases where it makes sense, but I don't think I have ever coded one.
> Probably >N (where N is the smallest reasonable output, defaulting 
> to 1) may be a better test in real code.

On older systems fprintf returns 0 on success and EOF on failure.

> As I recall, on SunOS 4 the printf()s don't return the number of 
> characters written.  I don't recall what they do instead, and have
> no access to such machines any more.

Probably 0/EOF.  sprintf on SunOS returns its first argument.

Ian

05 Jan 2001 14:26:13 -0800
Ian Lance Taylor <ian@airs.com>
Re: pg_dump return status..
>> An fprintf returning 0 is a suspicious event; it's easy to imagine 
>> cases where it makes sense, but I don't think I have ever coded one.
>> Probably > N (where N is the smallest reasonable output, defaulting 
>> to 1) may be a better test in real code.

> On older systems fprintf returns 0 on success and EOF on failure.

The books I have all recommend testing for "a negative return value"
to detect printf errors.  The C standard also specifies "a negative
value" for errors --- it is not guaranteed that that value is EOF.

			regards, tom lane

Fri, 05 Jan 2001 18:14:15 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump return status.. 
Nathan Myers writes:
 > On Fri, Jan 05, 2001 at 11:20:43AM -0500, Tom Lane wrote:
 > > Philip Warner <pjw@rhyme.com.au> writes:
 > > > how do I
 > > > check for a failed write in a way that works on all Unixes? Is the
 > > > following OK:
 > > 
 > > > - fwrite: ok if return value equals item count
 > > > - fprintf: ok if return value > 0.
 > > > - fputc: ok if != EOF
 > > 
 > > Probably fprintf() >= 0 --- according to my specs, it returns the number
 > > of chars emitted, or a negative value on error.  The other two are
 > > correct.
 > 
 > An fprintf returning 0 is a suspicious event; it's easy to imagine 
 > cases where it makes sense, but I don't think I have ever coded one.
 > Probably >N (where N is the smallest reasonable output, defaulting 
 > to 1) may be a better test in real code.
 > 
 > As I recall, on SunOS 4 the printf()s don't return the number of 
 > characters written.  I don't recall what they do instead, and have
 > no access to such machines any more.
 > 
 > Other old BSD-derived systems are likely to have have wonky return 
 > values/types on the printf()s.  Looking at the list of supported 
 > platforms, none jump out as likely candidates, but in the "unsupported" 
 > list, Ultrix and NextStep do.  (Do we care?)
 > 
 > If SunOS 4 is to remain a supported platform, the printf checks may 
 > need to be special-cased for it.

Current Solaris is liable to problems still, though these are not
relevant to this thread.  printf() and fprintf() have always returned
the number of characters transmitted, or EOF for failure.  It is
sprintf() that has problems.

There are two versions of sprintf() available in SunOS 4 - 8.  The
standard one (ANSI C) in libc returns an int, the number of characters
written (excluding '\0').  The BSD version returns a char* which
points to the target.  If you have a -lbsd on your link line then you
get the BSD version.  There are no compiler errors, just run time
errors if you rely on the return from sprintf() being the number of
characters.  The workaround is to put an extra -lc on the link line
before the -lbsd if your code needs both standard sprintf() and some
other BSD function.

Ultrix is documented as having the same behaviour as Solaris.  I don't
know about NeXTSTEP/OPENSTEP/GNUStep.
-- 
Pete Forman                 -./\.- Disclaimer: This post is originated
WesternGeco                   -./\.-  by myself and does not represent
pete.forman@westerngeco.com     -./\.-  opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef  -./\.-  Hughes or their divisions.

Mon, 8 Jan 2001 09:36:21 +0000
Pete Forman <pete.forman@westerngeco.com>
Re: pg_dump return status..
At 09:36 8/01/01 +0000, Pete Forman wrote:
>There are no compiler errors, just run time
>errors if you rely on the return from sprintf() being the number of
>characters.

All I need to know is how to detect an error. Does it return EOF on error?


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Mon, 08 Jan 2001 21:30:53 +1100
Philip Warner <pjw@rhyme.com.au>
Re: pg_dump return status..
Philip Warner writes:
 > At 09:36 8/01/01 +0000, Pete Forman wrote:
 > >There are no compiler errors, just run time errors if you rely on
 > >the return from sprintf() being the number of characters.
 > 
 > All I need to know is how to detect an error. Does it return EOF on
 > error?

The standard sprintf() returns a negative int on error.  That value
may or may not be EOF.  EOF technically indicates the end of an input
stream.  It has no direct connection with errors writing to streams.

The "BSD" version in Solaris always returns the char* pointer that is
the first argument.  There is no way to check for an error.

Other BSD OSs such as FreeBSD, NetBSD and OpenBSD all conform to C89,
i.e. sprintf() returns an int which is the number of characters
written (excluding '\0') or a negative number for failure.
-- 
Pete Forman                 -./\.- Disclaimer: This post is originated
WesternGeco                   -./\.-  by myself and does not represent
pete.forman@westerngeco.com     -./\.-  opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef  -./\.-  Hughes or their divisions.

Mon, 8 Jan 2001 11:16:00 +0000
Pete Forman <pete.forman@westerngeco.com>
Re: pg_dump return status..
Pete Forman <pete.forman@westerngeco.com> writes:
> Philip Warner writes:
>> All I need to know is how to detect an error. Does it return EOF on
>> error?

> The standard sprintf() returns a negative int on error.

I thought we were talking about fprintf.  sprintf can't really detect
any errors anyway, except maybe a bad format string.

			regards, tom lane

Mon, 08 Jan 2001 10:32:16 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_dump return status.. 
> There are two versions of sprintf() available in SunOS 4 - 8.  The
> standard one (ANSI C) in libc returns an int, the number of characters
> written (excluding '\0').  The BSD version returns a char* which
> points to the target.  If you have a -lbsd on your link line then you
> get the BSD version.  There are no compiler errors, just run time
> errors if you rely on the return from sprintf() being the number of
> characters.  The workaround is to put an extra -lc on the link line
> before the -lbsd if your code needs both standard sprintf() and some
> other BSD function.
> 
> Ultrix is documented as having the same behaviour as Solaris.  I don't
> know about NeXTSTEP/OPENSTEP/GNUStep.

Of course, if sprintf() returns an error, you have pretty big problems. 
:-)


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 9 Jan 2001 09:26:15 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: pg_dump return status..