Does not seem to respect --set ON_ERROR_STOP=1 #6
Comments
|
Hello Harry! Thanks for letting me know. I haven’t tested Par_psql with the last few major versions of Postgres. If I get time this week I’ll load it up and check what’s going on.
Graeme
… On 16 Dec 2021, at 12:50, Harry Biddle ***@***.***> wrote:
I'm invoking par_psql with --set ON_ERROR_STOP=1.
However, when one of my (parallelised) commands errored, par_psql continued on with the rest of the script.
I'll dig into it, but please let me know if you find a solution to this!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
breunigs
added a commit
to breunigs/par_psql
that referenced
this issue
Mar 24, 2023
The sub-shells exit code wasn't checked, so even if psql exited with a non-zero status code, par_psql would continue. We can check this directly for sequential queries, but need to do some housekeeping for the background processes. It is possible to exit immediately upon encountering a failed sub-shell, but the later ones might still be running and print into the terminal, leaving a dirty prompt. The exit code `3` is what `psql -v ON_ERROR_STOP=1` returns.
breunigs
added a commit
to breunigs/par_psql
that referenced
this issue
Mar 24, 2023
The sub-shells exit code wasn't checked, so even if psql exited with a non-zero status code, par_psql would continue. We can check this directly for sequential queries, but need to do some housekeeping for the background processes. It is possible to exit immediately upon encountering a failed sub-shell, but the later ones might still be running and print into the terminal, leaving a dirty prompt. The exit code `3` is what `psql -v ON_ERROR_STOP=1` returns.
breunigs
added a commit
to breunigs/par_psql
that referenced
this issue
Mar 24, 2023
The sub-shells exit code wasn't checked, so even if psql exited with a non-zero status code, par_psql would continue. We can check this directly for sequential queries, but need to do some housekeeping for the background processes. It is possible to exit immediately upon encountering a failed sub-shell, but the later ones might still be running and print into the terminal, leaving a dirty prompt. The exit code `3` is what `psql -v ON_ERROR_STOP=1` returns.
breunigs
added a commit
to breunigs/par_psql
that referenced
this issue
Mar 24, 2023
The sub-shells exit code wasn't checked, so even if psql exited with a non-zero status code, par_psql would continue. We can check this directly for sequential queries, but need to do some housekeeping for the background processes. It is possible to exit immediately upon encountering a failed sub-shell, but the later ones might still be running and print into the terminal, leaving a dirty prompt. The exit code `3` is what `psql -v ON_ERROR_STOP=1` returns.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm invoking par_psql with
--set ON_ERROR_STOP=1.However, when one of my (parallelised) commands errored, par_psql continued on with the rest of the script.
I'll dig into it, but please let me know if you find a solution to this!
The text was updated successfully, but these errors were encountered: