From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | psql exit status with multiple -c or -f |
Date: | 2018-12-17 17:58:41 |
Message-ID: | 20181217175841.GS13019@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Our deployment script failed to notice dozens of commands failed in a
transaction block and I only noticed due to keeping full logs and monitoring
for error_severity>'LOG'. I would have thought that exit status would be
nonzero had an error occured in an earlier script.
The docs since PG9.6 say:
https://www.postgresql.org/docs/9.6/app-psql.html
|Exit Status
|
|psql returns 0 to the shell if it finished normally, 1 if a fatal error of its
|own occurs (e.g. out of memory, file not found), 2 if the connection to the
|server went bad and the session was not interactive, and 3 if an error occurred
|in a script and the variable ON_ERROR_STOP was set.
d5563d7df94488bf0ab52ac0678e8a07e5b8297e
psql: Support multiple -c and -f options, and allow mixing them.
If there's an error, it returns 1 (although that's not "a fatal error of its
own").
|[pryzbyj(at)database ~]$ psql ts -c foo 2>/dev/null ; echo $?
|1
But the error is "lost" if another script or -c runs without failing:
|[pryzbyj(at)database ~]$ psql ts -txqc foo -c SELECT 2>/dev/null ; echo $?
|0
Note, this works as expected:
|[pryzbyj(at)database ~]$ psql ts -v ON_ERROR_STOP=1 -txqc foo -f /dev/null 2>/dev/null ; echo $?
|1
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Adam Brusselback | 2018-12-17 18:18:56 | Re: Referential Integrity Checks with Statement-level Triggers |
Previous Message | Pavel Stehule | 2018-12-17 17:45:53 | Re: Referential Integrity Checks with Statement-level Triggers |