From: | David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Rollback on include error in psql |
Date: | 2014-12-29 23:56:26 |
Message-ID: | CAKFQuwaM6Uniq+aDGF=Mfo4ec80WaxrEYNBrYd+hf-w0c2X+-w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-general |
On Mon, Dec 29, 2014 at 4:38 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:
> On 12/29/2014 02:55 PM, David Johnston wrote:
>
>> On Mon, Dec 29, 2014 at 3:37 PM, Adrian Klaver
>> <adrian(dot)klaver(at)aklaver(dot)com <mailto:adrian(dot)klaver(at)aklaver(dot)com>>wrote:
>>
>> On 12/29/2014 02:28 PM, David Johnston wrote:
>>
>> On Mon, Dec 29, 2014 at 3:07 PM, Adrian Klaver
>> <adrian(dot)klaver(at)aklaver(dot)com <mailto:adrian(dot)klaver(at)aklaver(dot)com>
>> <mailto:adrian(dot)klaver(at)aklaver(dot)__com
>>
>> <mailto:adrian(dot)klaver(at)aklaver(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-12-30 00:01:29 | Re: BUG #12368: Installation from source does not add libxml support even using --with-libxml. |
Previous Message | Adrian Klaver | 2014-12-29 23:38:30 | Re: [GENERAL] Rollback on include error in psql |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2014-12-30 00:00:05 | Re: Hostnames, IDNs, Punycode and Unicode Case Folding |
Previous Message | Mike Cardwell | 2014-12-29 23:50:54 | Re: Hostnames, IDNs, Punycode and Unicode Case Folding |