467,915 Members | 1,188 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,915 developers. It's quick & easy.

psql: immediately exit after an error?

Can psql be told to exit immediately after an error (especially when
doing commands from a file, -f)? This is the default behaviour of the
mysql client, except when we give it -f option ("force").

The problem is, when restoring a dump, a failure at the some point might
cause the subsequent commands to produce wrong results (e.g. I redefine
a builtin function with a plruby function with different behaviour, but
plruby failed to be installed due to wrong path. Thus the subsequent
commands are executed using the builtin function which is not the
expected one.) Furthermore, you can't check on psql exit code to see
whether _any_ command was not successfully executed.

Of course one should examine the full psql output after a restore
anyway, and the option to exit immediately after an error can save time
(especially for large dumps).

--
dave
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 23 '05 #1
  • viewed: 5416
Share:
4 Replies
I would think that depends upon how the sql in the file is coded. You can use the RAISE NOTICE / ERROR commands to abort a function's execution.
Can psql be told to exit immediately after an error (especially when
doing commands from a file, -f)? This is the default behaviour of the
mysql client, except when we give it -f option ("force").

The problem is, when restoring a dump, a failure at the some point might
cause the subsequent commands to produce wrong results (e.g. I redefine
a builtin function with a plruby function with different behaviour, but
plruby failed to be installed due to wrong path. Thus the subsequent
commands are executed using the builtin function which is not the
expected one.) Furthermore, you can't check on psql exit code to see
whether _any_ command was not successfully executed.

Of course one should examine the full psql output after a restore
anyway, and the option to exit immediately after an error can save time
(especially for large dumps).

--
dave
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 23 '05 #2
David Garamond wrote:
Can psql be told to exit immediately after an error (especially when
doing commands from a file, -f)? This is the default behaviour of the
mysql client, except when we give it -f option ("force").


\set ON_ERROR_STOP on

Look into the psql man page for additional semantic details.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 23 '05 #3
Peter Eisentraut wrote:
Can psql be told to exit immediately after an error (especially when
doing commands from a file, -f)? This is the default behaviour of the
mysql client, except when we give it -f option ("force").


\set ON_ERROR_STOP on

Look into the psql man page for additional semantic details.


Thanks! Just what I was looking for.

Btw, may I suggest this line be added by pg_dump/pg_dumpall? Or even the
default being changed to on when -f is given? Or maybe add a command
line option for this?

--
dave

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 23 '05 #4
David Garamond <li***@zara.6.isreserved.com> writes:
Peter Eisentraut wrote:
\set ON_ERROR_STOP on
Btw, may I suggest this line be added by pg_dump/pg_dumpall?


No. The fact that pg_dump scripts keep going is a feature, not a bug.
We recently changed pg_restore to match that behavior, in fact, because
people were constantly having trouble when it didn't.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Brendan Jurd | last post: by
15 posts views Thread by Dino Vliet | last post: by
2 posts views Thread by Russ Brown | last post: by
2 posts views Thread by Jeffrey W. Baker | last post: by
2 posts views Thread by Patrick Hatcher | last post: by
5 posts views Thread by damacy | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.