Open kwannoel opened 2 years ago
Working on shrinking the query.
Observed from main cron job: https://buildkite.com/singularity-data/main-cron. originates somewhere between recent commits: [730a8a3, c1ec8e5cbba07b34edf82fc1cfde9142e64f2a49)
How you know this is a stack overflow? Is there a log?
Sounds like parser recursive too much while processing the query...
How you know this is a stack overflow? Is there a log?
Updated in description, thanks
Seems like this is the commit: c275f7e0fc8de90f41de6361a7a7703f8f7cf05d after running git bisect
.
Seems like this is the commit: c275f7e after running
git bisect
.
Could I get your help to take a look too @liurenjie1024 ?
I guess in the future the system should figure out during optimization phase whether to use distributed / local execution mode. For now I will set sqlsmith to use distributed mode when executing. That should fix this bug.
Seems like this is the commit: c275f7e after running
git bisect
.Could I get your help to take a look too @liurenjie1024 ?
Yes, after this pr we changed default mode from distributed to local, so it's possible to incur overflow. Also agree that we should automatically determine execution mode by optimizer, but it's low priority.
cc @xxchan
Not fixed yet, only worked around in sqlsmith. Keep it open to track.
Fix is to automatically use distributed
execution mode when query is too large.
Found another stack overflow https://buildkite.com/risingwavelabs/pull-request/builds/52814#0190560f-6359-4d81-8d96-b02ed46c00cd
Describe the bug
Update: This is expected after switching to local execution mode that we may overflow on large queries. See comment below for more details: https://github.com/singularity-data/risingwave/issues/4807#issuecomment-1223608299.
We can fix it by configuring distributed execution mode in sqlsmith.
frontend.log
To Reproduce
Expected behavior A clear and concise description of what you expected to happen.
Additional context Add any other context about the problem here.