-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[YSQL] Getting conflicts on INSERT #2954
Comments
hi @jeffreims -- Thx for filing the issue. Can you also share the table DDL (including any indexes, foreign key constraints, etc.)? |
Given just the above information, this seems related to issue #2823. If that is the case, conflicts are expected behavior for the current serializable isolation level in Yugabyte. |
Just sent the schema internally. |
Wanted to share a quick update: I am able to reproduce this and see the same behavior - transaction conflicts and conflicts on the same transaction ID. |
Hi @jeffreims, I looked into this some more and this is expected behavior. Here's why: (1) Why are transaction conflicts expected? (2) Why does the same transaction number appear in multiple error messages? I'm closing this issue since it's expected behavior. Feel free to re-open if you have further questions. |
Hi @ndeodhar. Thanks so much for your help so far. I'm the author of the script that produced the conflicts.
This is not the case, which is why we are confused as to what the reason for these conflicts could be. The errors are produced by a single python script that executes all database mutations sequentially. This also means that a new attempt (by the same process) is only made after YB has communicated that the previous attempt has definitely failed. Additionally, the PK is a UUID randomly generated before each insert so even IF multiple scripts would be running concurrently, they would not write to the same PK value. We hope that you can shine some light on this! |
Hi @florishermsen
It seems like the same IDs are being inserted repeatedly, which is what led me to believe that the script is inserting duplicates. Can you please share the script that you used? I tried a multi-threaded sample program that generates UUIDs randomly and I don't run into this issue. So, it'll be helpful to have your script so we can better debug this. |
@ndeodhar You are correct that the same IDs are being inserted, but that's just because they are a retry of the same query by the same script. Note that after N retries, usually between N=1 and 10, the insert does succeed (still the exact same query). I'll try to make a small script that replicates what we do. |
@ndeodhar after upgrading to 2.0.6 we don't see these conflicts anymore (so far so good). The added support for foreign keys may have solved the issues. I think you can close this ticket for now! Thanks |
Good to hear that! Thanks for the update @florishermsen ! |
We are having a few issues with conflicting transactions. New unique INSERTs seem to conflict with select statements and in some cases inserts seem to be having conflicts with other (unique)
insert transactions
On our development boxes we're running a single node with RF set to 1.
Currently running version:
{"build_id": "", "build_hostname": "scheduler.c.yugabyte.internal", "build_number": "16", "version_number": "2.0.0.0", "build_clean_repo": "true", "build_username": "centos", "build_timestamp": "14 Sep 2019 18:43:22 UTC", "git_hash": "0b543e8ec9f16ae989ba29873e2d1d7977551b23", "build_type": "RELEASE"}
With:
default_transaction_isolation='serializable'
In the logs below we can see that transaction 58d240af-9e0c-4968-86d1-942ec06641e9 is conflicting on bb262c57-ce8e-40e3-bf6b-cef6709c92d0 and later some other insert statements are conflicting on 58d240af-9e0c-4968-86d1-942ec06641e9.
Some more logs:
The text was updated successfully, but these errors were encountered: