-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Fix postgres unique constraint exception #12373
Conversation
@ytzemih, can you test the build of this PR and check if it resolves the issue? I cannot reproduce the issue on my machine, so it's a bit difficult to debug or see the results. |
@LoayGhreeb Thanks for the candidate fix. Would you be able to rebuild the .deb in order for the new deb config to be applied? See #12370 |
Alright, I just updated the branch. The build will be available in 10 minutes. |
@LoayGhreeb Thanks for trying. For some reason, #12370 is still not fixed for my Linux. I can't install JR and I'm not keen on starting to backport/fiddle around with incompatible ALSA libraries. I hope, @Siedlerchr and I can figure that out soon and then I'll try again. |
The build for this PR is no longer available. Please visit https://builds.jabref.org/main/ for the latest build. |
@ytzemih there were missing a few lines in the yaml that needed to be adapted so no new build was produced. Should work now with build date 12.01.2025 |
@LoayGhreeb and @Siedlerchr, after a few days of working with that PR, neither the unique constraint exception (#12167) nor of the problems with the PostgreSQL (#12190) seem to show up. I'll be having an eye on this issue in the coming days, but it seems that this could be a fix. |
Ok, I think this issue is gone. I can't seem to get the unique constraint violations anymore. However, my hope about #12190 being fixed as well has gone. The latter still occurs. But I'll add further comments in the corresponding places. |
@LoayGhreeb I think we should merge this |
Attempt to fix #12167.
I cannot reproduce the issue on my machine, but I guess it may be related to background threads and quickly updating the entry.
One possible scenario is that the user is updating the field quickly, and updating the field is a critical section that should be completed as an atomic operation without interruptions.
The issue might occur if the first thread removes the field, but before it inserts the field again, another thread updates the same entry and also removes the field. This could result in both threads attempting to insert the same field into the table twice, violating the primary key constraint (
entryId
,fieldName
), which must be unique.Mandatory checks
CHANGELOG.md
described in a way that is understandable for the average user (if change is visible to the user)