-
Notifications
You must be signed in to change notification settings - Fork 848
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: 2.7.0 crashes when executing multiple IMMUTABLE functions (2.6.0 was fine) #4489
Labels
Comments
Hello @jflambert, Thanks for opening this issue. The problem seems to be related with calling an exception handler and using default parameters in a function. I was also able to reproduce this problem with a slightly simpler function (without using test2=# CREATE FUNCTION FUNCTION_HANDLE_EXCEPTION(TEXT DEFAULT '') RETURNS UUID AS $$
BEGIN
return $1::UUID;
EXCEPTION WHEN invalid_text_representation THEN
RETURN '00000000-0000-0000-0000-000000000000';
END;
$$ LANGUAGE PLPGSQL IMMUTABLE;
CREATE FUNCTION
test2=#
# Works
test2=# SELECT DEFAULT_UUID('d482b36a-fc4a-11ec-b939-0242ac120002'), DEFAULT_UUID('d482b36a-fc4a-11ec-b939-0242ac120002');
default_uuid | default_uuid
--------------------------------------+--------------------------------------
d482b36a-fc4a-11ec-b939-0242ac120002 | d482b36a-fc4a-11ec-b939-0242ac120002
(1 row)
# Crashes
test2=# SELECT DEFAULT_UUID(), DEFAULT_UUID(); Stacktrace
Full Stacktrace
|
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
Jul 5, 2022
Executing an IMMUTABLE function that has parameters and exception handling block multiple times in the same transaction causes a null pointer exception when try to reset and unitialized `ts_baserel_info`. Fixed it by preventing to reset a non-initialized `ts_baserel_info`. Fixes timescale#4489
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
Jul 5, 2022
Executing an IMMUTABLE function that has parameters and exception handling block multiple times in the same transaction causes a null pointer segfault when try to reset an non-initialized ts_baserel_info. Fixed it by preventing to reset a non-initialized `ts_baserel_info`. Fixes timescale#4489
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
Jul 5, 2022
Executing an IMMUTABLE function that has parameters and exception handling block multiple times in the same transaction causes a null pointer segfault when try to reset a non-initialized ts_baserel_info. Fixed it by preventing to reset a non-initialized `ts_baserel_info`. Fixes timescale#4489
fabriziomello
added a commit
that referenced
this issue
Jul 5, 2022
Executing an IMMUTABLE function that has parameters and exception handling block multiple times in the same transaction causes a null pointer segfault when try to reset a non-initialized ts_baserel_info. Fixed it by preventing to reset a non-initialized `ts_baserel_info`. Fixes #4489
mkindahl
pushed a commit
that referenced
this issue
Jul 5, 2022
Executing an IMMUTABLE function that has parameters and exception handling block multiple times in the same transaction causes a null pointer segfault when try to reset a non-initialized ts_baserel_info. Fixed it by preventing to reset a non-initialized `ts_baserel_info`. Fixes #4489
mkindahl
pushed a commit
that referenced
this issue
Jul 6, 2022
Executing an IMMUTABLE function that has parameters and exception handling block multiple times in the same transaction causes a null pointer segfault when try to reset a non-initialized ts_baserel_info. Fixed it by preventing to reset a non-initialized `ts_baserel_info`. Fixes #4489
thank you for the swift fix, looking forward to 2.7.1 |
mkindahl
pushed a commit
that referenced
this issue
Jul 7, 2022
Executing an IMMUTABLE function that has parameters and exception handling block multiple times in the same transaction causes a null pointer segfault when try to reset a non-initialized ts_baserel_info. Fixed it by preventing to reset a non-initialized `ts_baserel_info`. Fixes #4489
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What type of bug is this?
Crash
What subsystems and features are affected?
Command processing
What happened?
Consider the following SQL
This function handles invalid/incomplete UUIDs and returns a "default one" when the conversion is impossible. We use it a lot when processing data from third-party sources.
It's marked immutable since it is
guaranteed to return the same results given the same arguments forever
. This normally provides a minor performance boost, and the execution would be inlined if it was SQL instead of PLPGSQL.Now let's execute the same function twice in a "transaction".
With timescale 2.6.1, this would return two "default" UUIDs. With 2.7.0, execution dies after 15 seconds with the error:
The server logs mention a segmentation fault (see below).
Now, recreate the same function but without IMMUTABLE, and Timescale 2.7.0 will happily execute it twice.
TimescaleDB version affected
2.7.0
PostgreSQL version used
13.7 (also tested on 12)
What operating system did you use?
Ubuntu 18.04
What installation method did you use?
Docker
What platform did you run on?
On prem/Self-hosted
Relevant log output and stack trace
How can we reproduce the bug?
The text was updated successfully, but these errors were encountered: