Thread: New parameter RollbackError to control rollback behavior on error
Hi all, The behavior of rollback when an error occurs on an handle is controlled by extending Protocol with "$PROTNUM-[0|1|2]" where: - 0 = let the application handle rollbacks - 1 = rollback whole transaction when an error occurs - 2 = rollback only statement that failed Using such an extension is somewhat awkward as a single string is used for two settings... The proposed attached patch adds a new parameter called RollbackError that allows to control the behavior of rollback on error with a different parameter. For backward-compatibility purposes, this patch does not break the old grammar of Protocol: it just gives the priority to RollbackError if both Protocol and RollbackError are set for a connection. Regression tests to test RollbackError and combinations of RollbackError/Protocol are added in the patch in the existing test error-rollback (which has needed some refactoring, older tests are not impacted). Docs are included as well. I thought first about including that in my cleanup work for 9.4, but as this actually does not break the driver it may be worth adding it directly to master, explaining the patch attached here. Comments welcome. Note that if there are objections I do not mind adding that for the work that would be merged later to 9.4 builds. Regards, -- Michael
Attachment
On 03/26/2014 08:39 AM, Michael Paquier wrote: > Hi all, > > The behavior of rollback when an error occurs on an handle is > controlled by extending Protocol with "$PROTNUM-[0|1|2]" where: > - 0 = let the application handle rollbacks > - 1 = rollback whole transaction when an error occurs > - 2 = rollback only statement that failed > Using such an extension is somewhat awkward as a single string is used > for two settings... The proposed attached patch adds a new parameter > called RollbackError that allows to control the behavior of rollback > on error with a different parameter. Great! Since we're designing a new user interface for this, let's try to make it as user-friendly as possible: * I'm not too fond of the RollbackError name. It sounds like "an error while rolling back". I googled around and found out that DataDirect's proprietary driver has the same option, and they call it TransactionErrorBehavior. See http://blogs.datadirect.com/2013/07/solution-unexpected-postgres-current-transaction-aborted-error.html. * Instead of using 0-2 as the values, let's give them descriptive names. Something like "none", "RollbackTransaction", "RollbackStatement". (actually, we'll probably want to also allow the integers, to keep the connection string short, as there is a size limit on that) > I thought first about including that in my cleanup work for 9.4, but > as this actually does not break the driver it may be worth adding it > directly to master, explaining the patch attached here. Comments > welcome. Note that if there are objections I do not mind adding that > for the work that would be merged later to 9.4 builds. Yeah, let's get this into the master branch before your big 9.4 cleanup work. - Heikki
On Wed, Mar 26, 2014 at 3:39 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > Hi all, > > The behavior of rollback when an error occurs on an handle is > controlled by extending Protocol with "$PROTNUM-[0|1|2]"... My apologies. This message was sent to the wrong mailing list and was dedicated to odbc. Once again sorry for that. -- Michael
Hi Michael, Isn't it an ODBC issue? regards, Hiroshi Inoue (2014/03/26 15:39), Michael Paquier wrote: > Hi all, > > The behavior of rollback when an error occurs on an handle is > controlled by extending Protocol with "$PROTNUM-[0|1|2]" where: > - 0 = let the application handle rollbacks > - 1 = rollback whole transaction when an error occurs > - 2 = rollback only statement that failed > Using such an extension is somewhat awkward as a single string is used > for two settings... The proposed attached patch adds a new parameter > called RollbackError that allows to control the behavior of rollback > on error with a different parameter. > > For backward-compatibility purposes, this patch does not break the old > grammar of Protocol: it just gives the priority to RollbackError if > both Protocol and RollbackError are set for a connection. Regression > tests to test RollbackError and combinations of RollbackError/Protocol > are added in the patch in the existing test error-rollback (which has > needed some refactoring, older tests are not impacted). Docs are > included as well. > > I thought first about including that in my cleanup work for 9.4, but > as this actually does not break the driver it may be worth adding it > directly to master, explaining the patch attached here. Comments > welcome. Note that if there are objections I do not mind adding that > for the work that would be merged later to 9.4 builds. > > Regards,
On Wed, Mar 26, 2014 at 5:53 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > * I'm not too fond of the RollbackError name. It sounds like "an error while > rolling back". I googled around and found out that DataDirect's proprietary > driver has the same option, and they call it TransactionErrorBehavior. See > http://blogs.datadirect.com/2013/07/solution-unexpected-postgres-current-transaction-aborted-error.html. > > * Instead of using 0-2 as the values, let's give them descriptive names. > Something like "none", "RollbackTransaction", "RollbackStatement". > (actually, we'll probably want to also allow the integers, to keep the > connection string short, as there is a size limit on that) OK, I have been working more on that, giving the attached patch. The parameter name is changed to TransactionErrorBehavior, able to use the values "Statement", "Nop", "Transaction" and "Default". "Default" corresponds to the default behavior, that is used to set the rollback behavior depending on the Postgres version driver is connected with. As of now, TransactionErrorBehavior does not accept integer values as it makes the patch a bit more simple, this could be added with some atoi calls in dlg_specific.c. I have updated dlg_wingui.c as well. Patch has always its set of docs and regression tests. Regards, -- Michael
Attachment
On Mon, Mar 31, 2014 at 9:40 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > OK, I have been working more on that, giving the attached patch... Sorry, wrong mailing list... My apologies. -- Michael