-
Notifications
You must be signed in to change notification settings - Fork 907
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]: Crash in planner for JOIN queries. #4148
Comments
@svenklemm I cannot reproduce the crash with the DB and query provided. Is it possible to provide a stack trace with debug symbols? Or, run |
|
I think I have found the issue, but need to verify the fix. Essentially, the issue is that a rescan is initiated on a per-tuple memory context. |
Scan functions cannot be called on a per-tuple memory context as they might allocate data that need to live until the end of the scan. Fix this in a couple of places to ensure correct memory handling. Fixes timescale#4148, timescale#4145
@erimatnor if you have branch you can point me to i can check if it is fixed |
Scan functions cannot be called on a per-tuple memory context as they might allocate data that need to live until the end of the scan. Fix this in a couple of places to ensure correct memory handling. Fixes timescale#4148, timescale#4145
There's a PR, linked above. |
Scan functions cannot be called on a per-tuple memory context as they might allocate data that need to live until the end of the scan. Fix this in a couple of places to ensure correct memory handling. Fixes timescale#4148, timescale#4145
Scan functions cannot be called on a per-tuple memory context as they might allocate data that need to live until the end of the scan. Fix this in a couple of places to ensure correct memory handling. Fixes timescale#4148, timescale#4145
Scan functions cannot be called on a per-tuple memory context as they might allocate data that need to live until the end of the scan. Fix this in a couple of places to ensure correct memory handling. Fixes timescale#4148, timescale#4145
Scan functions cannot be called on a per-tuple memory context as they might allocate data that need to live until the end of the scan. Fix this in a couple of places to ensure correct memory handling. Fixes timescale#4148, timescale#4145
Scan functions cannot be called on a per-tuple memory context as they might allocate data that need to live until the end of the scan. Fix this in a couple of places to ensure correct memory handling. Fixes timescale#4148, timescale#4145
Scan functions cannot be called on a per-tuple memory context as they might allocate data that need to live until the end of the scan. Fix this in a couple of places to ensure correct memory handling. Fixes timescale#4148, timescale#4145
Scan functions cannot be called on a per-tuple memory context as they might allocate data that need to live until the end of the scan. Fix this in a couple of places to ensure correct memory handling. Fixes timescale#4148, timescale#4145
What type of bug is this?
Crash
What subsystems and features are affected?
Other
What happened?
TimescaleDB crashes on certain queries, this seems to be very easy to trigger as I get roughly 30 coredumps per minute with sqlsmith.
I will update ticket with more information once i have reproducer.
TimescaleDB version affected
master
PostgreSQL version used
14.2
What operating system did you use?
Archlinux 2022.03.01 x64
What installation method did you use?
Source
What platform did you run on?
On prem/Self-hosted
Relevant log output and stack trace
How can we reproduce the bug?
The database used is the one from regresscheck-shared.
The text was updated successfully, but these errors were encountered: