Andrew Dunstan <andrew@dunslane.net> writes:
> As I was giving this a final polish I noticed this in jspConvertRegexFlags:
> /*
> * We'll never need sub-match details at execution. While
> * RE_compile_and_execute would set this flag anyway, force it on here to
> * ensure that the regex cache entries created by makeItemLikeRegex are
> * useful.
> */
> cflags |= REG_NOSUB;
> Clearly the comment would no longer be true. I guess I should just
> remove this?
Yeah, we can just drop that I guess. I'm slightly worried that we might
need it again after some future refactoring; but it's not really worth
devising a re-worded comment to justify keeping it.
Also, I realized that I failed in my reviewerly duty by not noticing
that you'd forgotten to pg_regfree the regex after successful
compilation. Running something like this exposes the memory leak
very quickly:
select pg_input_is_valid('$ ? (@ like_regex "pattern" flag "smixq")', 'jsonpath')
from generate_series(1,10000000);
The attached delta patch takes care of it. (Per comment at pg_regcomp,
we don't need this after a failure return.)
regards, tom lane
diff --git a/src/backend/utils/adt/jsonpath_gram.y b/src/backend/utils/adt/jsonpath_gram.y
index 8c3a0c7623..30179408f5 100644
--- a/src/backend/utils/adt/jsonpath_gram.y
+++ b/src/backend/utils/adt/jsonpath_gram.y
@@ -560,6 +560,8 @@ makeItemLikeRegex(JsonPathParseItem *expr, JsonPathString *pattern,
(errcode(ERRCODE_INVALID_REGULAR_EXPRESSION),
errmsg("invalid regular expression: %s", errMsg)));
}
+
+ pg_regfree(&re_tmp);
}
*result = v;