Re: Rollback on include error in psql - Mailing list pgsql-general
| From | David Johnston |
|---|---|
| Subject | Re: Rollback on include error in psql |
| Date | |
| Msg-id | CAKFQuwaM6Uniq+aDGF=Mfo4ec80WaxrEYNBrYd+hf-w0c2X+-w@mail.gmail.com Whole thread Raw |
| In response to | Re: Rollback on include error in psql (Adrian Klaver <adrian.klaver@aklaver.com>) |
| Responses |
Re: Rollback on include error in psql
|
| List | pgsql-general |
On Mon, Dec 29, 2014 at 4:38 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 12/29/2014 02:55 PM, David Johnston wrote:On Mon, Dec 29, 2014 at 3:37 PM, Adrian Klaver
<adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>>wrote:
On 12/29/2014 02:28 PM, David Johnston wrote:
On Mon, Dec 29, 2014 at 3:07 PM, Adrian Klaver
<adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
<mailto:adrian.klaver@aklaver.__com
<mailto:adrian.klaver@aklaver.com>>>wrote:
On 12/29/2014 09:38 AM, David Johnston wrote:
This is one of those glass half full/empty situations,
where it is
down to the eye of the beholder. I would also say
this a
perfect
example of why tests are written, to see what
actually happens
versus what you think happens.
If a user of our product needs to run a test to determine
behavior then
our documentation is flawed - which is the point I am
making.
Still not seeing the flaw in the documentation.
...
psql does not see any error due to meta-commands or
SQL as fatal -
which is why the ON_ERROR_STOP option exists.
And ON_ERROR_STOP does not change that. All it does is toggle
whether psql continues on after an error or stops
processing commands.
If it walks and talks like a duck...the fact that ON_ERROR_STOP
makes
psql halt processing means that it now treats them like it does any
other fatal error.
But it does not:
ON_ERROR_STOP
By default, command processing continues after an error. When
this variable is set, it will instead stop immediately. In
interactive mode, psql will return to the command prompt; otherwise,
<HIGHLIGHT> psql will exit, returning error code 3 to distinguish
this case from fatal error conditions, which are reported using
error code 1.<HIGHLIGHT>
In either case, any currently running scripts (the top-level script,
if any, and any other scripts which it may have in invoked) will be
terminated immediately. If the top-level command string contained
multiple SQL commands, processing will stop with the current command.
I am not seeing what point you are trying to make here. psql exits -
my contention is that it should do so before issuing "COMMIT;" if
--single-transaction was specified. I really don't care what made psql
exit - a fatal error or a non-fatal one while running under ON_ERROR_STOP.
I am having trouble keeping up with this line of reasoning:
"psql does not see any error due to meta-commands or SQL as fatal - which is why the ON_ERROR_STOP option exists.
"
"
If it walks and talks like a duck...the fact that ON_ERROR_STOP
makes psql halt processing means that it now treats them like it does any other fatal error.
"
"I really don't care what made psql exit.."
At this point I agree to disagree.
OK - what do we disagree on? This is nit-picking on a few word choices.
psql is a client not an all knowing entity. Not sure it is in its remit to monitor all possible interactions of database commands and non database commands. For instance, you have in a script a function written in plpythonu that sends email and in the same script a line that runs that function to send an email. Do you expect psql to abort everything if the receiving email server rejects the message? A contrived example to be sure, but not entirely out of the realm of possibility and journey done a tortuous path
Not productive - since plpython is outside of its purvue it cannot control that. However, right now if that function raises an error the script should stop and the open transaction should be rolled back (by default). If something is non-transaction and cannot be rolled back (notify, writing to file system, etc...) then that effect remains just like it would in any other situation. But psql does have full control over "\include" and should handle a failure to do so like any other scripting language interpreter would.
Just not seeing it. At this point I have made my arguments. Will be interested whether others have comments or even care.
So you think psql should issue "COMMIT;" even if it is exiting due to "ON_ERROR_STOP"?
Whether you do or don't can you show me where in the documentation the current behavior is described?
David J.
pgsql-general by date: