Thread: RE: [GENERAL] pg_dump return status..
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 >
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 |/
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
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 |/
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
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
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
>> 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
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 whereit 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 oldBSD-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 wecare?)> > 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.
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 |/
Philip Warner writes:> At 09:36 8/01/01 +0000, Pete Forman wrote:> >There are no compiler errors, just run time errors ifyou 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.
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
> 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, Pennsylvania19026