Don't capture hard errors in with-clause parser #7893
+350
−191
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
erimatnor
reviewed
Apr 1, 2025
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7893 +/- ##
==========================================
+ Coverage 80.06% 81.90% +1.83%
==========================================
Files 190 249 +59
Lines 37181 46154 +8973
Branches 9450 11573 +2123
==========================================
+ Hits 29770 37801 +8031
- Misses 2997 3790 +793
- Partials 4414 4563 +149 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
mkindahl
force-pushed
the
dont-capture-hard-errors
branch
from
a55c32a to
d724332
Compare
mkindahl
force-pushed
the
dont-capture-hard-errors
branch
4 times, most recently
from
7fc20c2 to
fe5e185
Compare
mkindahl
force-pushed
the
dont-capture-hard-errors
branch
from
fe5e185 to
fc706ec
Compare
erimatnor
reviewed
Apr 2, 2025
mkindahl
changed the title
mkindahl
force-pushed
the
dont-capture-hard-errors
branch
from
fc706ec to
eb1d453
Compare
mkindahl
force-pushed
the
dont-capture-hard-errors
branch
from
eb1d453 to
f476732
Compare
fabriziomello
approved these changes
Apr 2, 2025
mkindahl
force-pushed
the
dont-capture-hard-errors
branch
from
f476732 to
c028577
Compare
erimatnor
reviewed
Apr 4, 2025
| @@ -161,12 +161,38 @@ parse_arg(WithClauseDefinition arg, DefElem *def) | |||
|
|
|||
| Assert(OidIsValid(in_fn)); | |||
|
|
|||
| /* | |||
There was a problem hiding this comment.
Can you explain why all this pg_try-catch thing is needed?
I am asking because it looks like we are either rethrowing the error or just replacing it with another one. So why don't we just let the function call fail with whatever error it is throwing without capturing it?
Is it because we want to rewrite the error to something more user-friendly? I am wondering why we need to rewrite the error.
There was a problem hiding this comment.
AFAICT, it was only added for rewriting the error to something more user-friendly (see 3ef6732).
mkindahl
force-pushed
the
dont-capture-hard-errors
branch
6 times, most recently
from
9a53848 to
da5e7b2
Compare
mkindahl
force-pushed
the
dont-capture-hard-errors
branch
from
da5e7b2 to
1fa1462
Compare
When parsing WITH clause arguments for ALTER TABLE to extract compression parameters, syntax errors in the text format are caught using PG_TRY and PG_CATCH and then returning an indication if the parse succeeded or not. If an out-of-memory error occurs inside execution of the input function and this error is caught, it can continue executing and potentially cause cascading out-of-memory errors and in the end exhausting the error stack. This commit solves this by using checking the category of the thrown error and only allow errors in the data exception and the syntax errors and access rules violation category, which are "soft" errors in this case. Hard errors, like out-of-memory errors, are re-thrown allowing the backend to deal with it properly. It also adds tests and test utilities that allow you to raise an error of an arbitrary category when converting a string to the type.
mkindahl
force-pushed
the
dont-capture-hard-errors
branch
from
1fa1462 to
5c62687
Compare
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.
When parsing WITH clause arguments for ALTER TABLE to extract compression parameters, syntax errors in the text format are caught using PG_TRY and PG_CATCH and then returning an indication if the parse succeeded or not.
If an out-of-memory error occurs inside execution of the input function and this error is caught, it can continue executing and potentially cause cascading out-of-memory errors and in the end exhausting the error stack.
This commit solves this by using checking the category of the thrown error and only allow errors in the data exception and the syntax errors and access rules violation category, which are "soft" errors in this case. Hard errors, like out-of-memory errors, are re-thrown allowing the backend to deal with it properly.