-
Notifications
You must be signed in to change notification settings - Fork 421
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
Complex MERGE
causes crash
#897
Comments
|
@DominicWuest This crash is resolved in the master and is due to variable reuse for labels. Currently, multiple labels are not supported. Additionally, we are still working on allowing variable reuse with labels.
|
@DominicWuest Actually, I take that back. I was able to get it to crash. |
@jrgemignani @DominicWuest I am currently on the latest commit and I cannot get this to crash Edit: I am running it on an empty database, it just throws this error:
|
|
|
Here is a slightly less complicated command that exhibits both errors -
It appears that this MERGE bug has to do with memory allocation. It seems likely that the successive tuple creates aren't properly allocating tuples. |
I have created PR #957 to address some of these crashes. It won't address all of them, but it will help to isolate the ones that remain. Basically, there are multiple paths for some of these complex MERGEs to cause a crash, this PR addresses some of those paths. |
Fixed the complex MERGE crash, which was due to storing variables in tuple positions that did not exist. This happened on MERGE commands where there wasn't a RETURN clause. Added logic to catch these and handle appropriately. Meaning, discarding the variable results, instead of storing them. Fixing this issue has highlighted the need to fix variable reuse in the MERGE transform itself. This is because MERGE preprocesses the path before handing it off to anything else. Added regression tests.
Fixed the complex MERGE crash, which was due to storing variables in tuple positions that did not exist. This happened on MERGE commands where there wasn't a RETURN clause. Added logic to catch these and handle appropriately. Meaning, discarding the variable results, instead of storing them. Fixing this issue has highlighted the need to fix variable reuse in the MERGE transform itself. This is because MERGE preprocesses the path before handing it off to anything else. Added regression tests.
PR #961 addresses the source of -> this <- crash. So, this should now be corrected in the master branch. |
I found a bug using my cypher fuzzer.
When running the following query against an empty database:
The postgres instance crashes and goes into recovery mode.
I encountered this issue when testing queries against the apache/age:PG13_latest docker image.
Steps to reproduce
Spin up a local instance of apache/age:PG13_latest:
docker run -e POSTGRES_PASSWORD=123 --rm --name age apache/age:PG13_latest
Get a shell in the docker container:
docker exec -it age /bin/bash
Connect to postgres:
su postgres -c psql
Run the following queries:
Expected behavior
The query should run successfully
Actual behavior
The database crashes
The text was updated successfully, but these errors were encountered: