-
Notifications
You must be signed in to change notification settings - Fork 649
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: can't call parameterized distributed procedures outside an explicit transaction in Citus 12.1.3 (but not 12.1.0?) #7597
Comments
DS-AdamMilazzo
changed the title
BUG: transaction lost calling a distributed procedure in Citus 12.1.3 (but 12.1.0 works)
BUG: transaction lost calling a distributed procedure in Citus 12.1.3 (but not 12.1.0?)
May 10, 2024
DS-AdamMilazzo
changed the title
BUG: transaction lost calling a distributed procedure in Citus 12.1.3 (but not 12.1.0?)
BUG: can't call parameterized distributed procedures outside an explicit transaction in Citus 12.1.3 (but not 12.1.0?)
May 10, 2024
I have tried to reproduce this using the below python code. However on both 12.1.0 and 12.1.3, procedure f is called, it throws division by 0 exception and nothing is inserted to the table t. Is anything missing in this code?
|
I am not familiar with the python client, but I think there are two problems with that code.
|
Any luck reproducing this? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In Citus 12.1.3, when calling a distributed procedure in a batch of SQL statements, the CALL statement appears to execute in a different transaction from the rest of the statements in the batch. Also, it is generally impossible to call distributed procedures with batch parameters as arguments to the procedure. This behavior is not observed in Citus 12.1.0.
Repro steps
First, perform this setup:
Second, call the procedure in a parameterized batch of SQL statements:
In this batch, I used parameters
@0
= 1 and@1
= 2, but the specific values don't matter. The batch was sent with the Npgsql library, but any library that allows sending parameterized batches should be able to reproduce this bug. (Don't try putting the statements into a SQL procedure and calling it. That's not likely to reproduce the problem. Use a client library to send the parameterized batch.) Example Npgsql code:Expected behavior:
f(1, 2)
should be called, and fail with a division by zero error.Actual behavior:
f
is not called. Instead, an error occurs: "42P02: there is no parameter $1"Additional Comments
CALL f(1, @0);
it will fail.create_distributed_function
, the problem does not occur.BEGIN; INSERT ...; CALL ...; COMMIT;
CALL f(1, 2);
f
is supposed to succeed or fail. It never gets called in the first place.The text was updated successfully, but these errors were encountered: