Re: [GENERAL] Rollback on include error in psql - Mailing list pgsql-bugs
| From | David Johnston |
|---|---|
| Subject | Re: [GENERAL] Rollback on include error in psql |
| Date | |
| Msg-id | CAKFQuwaEKnoP1i8CpHwn9_H1Wma5vRf13oinz1tdZ=MOpYek7Q@mail.gmail.com Whole thread Raw |
| In response to | Re: [GENERAL] Rollback on include error in psql (Adrian Klaver <adrian.klaver@aklaver.com>) |
| Responses |
Re: [GENERAL] Rollback on include error in psql
|
| List | pgsql-bugs |
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.
I believe that if ON_ERROR_STOP causes an abort that the COMMIT from
--single-transaction should not run. That is a behavior change. But
not documenting the known and deterministic interaction between the two
options is a bug.
I am not seeing anything in the below that says an ABORT is issued:
I was using term in its non-SQL sense: to stop processing and return control to the user.
2) the implications of \include being a client-side mechanic and thus,
invisible to the server, is not well explained. Specifically that a
failure to include is the equivalent of simply omitting the statement
altogether (aside from the psql warning). i.e., if in an actual
transaction the server will not issue the standard "error has occurred,
you must ROLLBACK." message for any subsequent statements in the
script. This is probably not to the level of a bug but it is related to
the ON_ERROR_STOP bug.
I could see improving the wording on this, to let the user know that includes are on them as Viktor already determined and took action on.
I think you have a typo somewhere here 'cause that sentence fragment (...includes and on them as) makes no sense to me.
The overall complaint is that a missing \include file, without ON_ERROR_STOP, ends up being totally ignored even while in non-interactive mode. I get the benefit to that behavior in interactive mode and so being required to use ON_ERROR_STOP in script mode (which is the safest practice anyway) isn't that big a deal as long as in that mode a failure causes an immediate stop without any other SQL being sent to the server and, by extension, the session closing and effecting a rollback in the process if in --single-transaction mode just like that mode promises.
I'm not sure why --single-transaction even exists TBH. The script should determine its desired transaction modes and not leave the decision up to the caller. If the script relies on all-or-nothing it should have explicit BEGIN/COMMIT statements.
That said it does exist so it should play nicely with ON_ERROR_STOP. It currently does not nor is the not-nice interaction documented anywhere.
David J.
pgsql-bugs by date: