Fix transaction leak when DMLs contains a non pltsql language function which calls another non tsql function inside try catch #3217
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Pull Request Test Coverage Report for Build 12281033050Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
tanscorpio7
force-pushed
the
BABEL_5446
branch
from
9b5ecd8 to
c9323eb
Compare
tanscorpio7
changed the title
tanscorpio7
force-pushed
the
BABEL_5446
branch
from
c9323eb to
93cbed0
Compare
Signed-off-by: Tanzeel Khan <[email protected]>
tanscorpio7
force-pushed
the
BABEL_5446
branch
from
93cbed0 to
3848657
Compare
| @@ -4622,6 +4622,7 @@ exec_stmt_execsql(PLtsql_execstate *estate, | |||
| bool fmtonly_enabled = true; | |||
| CmdType cmd = CMD_UNKNOWN; | |||
| bool enable_txn_in_triggers = !pltsql_disable_txn_in_triggers; | |||
| bool support_tsql_trans = pltsql_support_tsql_transactions(); | |||
There was a problem hiding this comment.
Please see if this fix is needed for other callers of pltsql_support_tsql_transactions
There was a problem hiding this comment.
Also made this change in pltsql_exec_trigger. Change was not needed there, but did it anyway for consistency in code.
Signed-off-by: Tanzeel Khan <[email protected]>
surendravishnoi
approved these changes
Dec 12, 2024
shardgupta
merged commit 8d92966
into
babelfish-for-postgresql:BABEL_5_X_DEV
44 checks passed
tanscorpio7
added a commit
to tanscorpio7/babelfish_extensions
that referenced
this pull request
Dec 18, 2024
…n which calls another non tsql function inside try catch (babelfish-for-postgresql#3217) When DMLs are executed outside a user transaction block, babelfish starts an implicit transaction to handle errors inside triggers. This is done irrespective of whether the statement actually fires a trigger. Now if the DML calls a non pltsql function which in calls another non tsql func or procedure inside a try catch, we do not properly decrement the pltsql_sys_func_entry_count variable properly. So the return value of pltsql_support_tsql_transactions() is different at beginning of the DML compared to after the end of the statement. This difference leads to babelfish not commit the implict transaction block. As a fix, store the value of pltsql_support_tsql_transactions() at start of execution of DML and just reuse it for after execution. Issues Resolved: [BABEL-5446] Signed-off-by: Tanzeel Khan [email protected]
1 task
tanscorpio7
added a commit
to tanscorpio7/babelfish_extensions
that referenced
this pull request
Dec 18, 2024
…n which calls another non tsql function inside try catch (babelfish-for-postgresql#3217) When DMLs are executed outside a user transaction block, babelfish starts an implicit transaction to handle errors inside triggers. This is done irrespective of whether the statement actually fires a trigger. Now if the DML calls a non pltsql function which in calls another non tsql func or procedure inside a try catch, we do not properly decrement the pltsql_sys_func_entry_count variable properly. So the return value of pltsql_support_tsql_transactions() is different at beginning of the DML compared to after the end of the statement. This difference leads to babelfish not commit the implict transaction block. As a fix, store the value of pltsql_support_tsql_transactions() at start of execution of DML and just reuse it for after execution. Issues Resolved: [BABEL-5446] Signed-off-by: Tanzeel Khan [email protected]
shardgupta
pushed a commit
that referenced
this pull request
Dec 18, 2024
…n which calls another non tsql function inside try catch (#3217) (#3272) When DMLs are executed outside a user transaction block, babelfish starts an implicit transaction to handle errors inside triggers. This is done irrespective of whether the statement actually fires a trigger. Now if the DML calls a non pltsql function which in calls another non tsql func or procedure inside a try catch, we do not properly decrement the pltsql_sys_func_entry_count variable properly. So the return value of pltsql_support_tsql_transactions() is different at beginning of the DML compared to after the end of the statement. This difference leads to babelfish not commit the implict transaction block. As a fix, store the value of pltsql_support_tsql_transactions() at start of execution of DML and just reuse it for after execution. Issues Resolved: [BABEL-5446] Signed-off-by: Tanzeel Khan [email protected]
shardgupta
pushed a commit
that referenced
this pull request
Dec 18, 2024
…n which calls another non tsql function inside try catch (#3217) (#3273) When DMLs are executed outside a user transaction block, babelfish starts an implicit transaction to handle errors inside triggers. This is done irrespective of whether the statement actually fires a trigger. Now if the DML calls a non pltsql function which in calls another non tsql func or procedure inside a try catch, we do not properly decrement the pltsql_sys_func_entry_count variable properly. So the return value of pltsql_support_tsql_transactions() is different at beginning of the DML compared to after the end of the statement. This difference leads to babelfish not commit the implict transaction block. As a fix, store the value of pltsql_support_tsql_transactions() at start of execution of DML and just reuse it for after execution. Issues Resolved: [BABEL-5446] Signed-off-by: Tanzeel Khan [email protected]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
When DMLs are executed outside a user transaction block, babelfish starts an implicit transaction to handle errors inside triggers. This is done irrespective of whether the statement actually fires a trigger.
Now if the DML calls a non pltsql function which in calls another non tsql func or procedure inside a try catch, we do not properly decrement the
pltsql_sys_func_entry_countvariable properly. So the return value ofpltsql_support_tsql_transactions()is different at beginning of the DML compared to after the end of the statement. This difference leads to babelfish not commit the implict transaction block.As a fix, store the value of pltsql_support_tsql_transactions() at start of execution of DML and just reuse it for after execution.
Issues Resolved
[BABEL-5446]
Sign Off
Signed-off-by: Tanzeel Khan [email protected]
Check List
By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.