-
Notifications
You must be signed in to change notification settings - Fork 265
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
Posgres: fix concurrency in channels db #1762
Conversation
This test unveils a concurrency issue in the upsert logic of the local channels db, with the following error being thrown when we update many channels concurrently: ``` Canceled on identification as a pivot, during conflict out checking ```
This is the recommended pattern according to postgres doc (https://www.postgresql.org/docs/current/plpgsql-control-structures.html#PLPGSQL-UPSERT-EXAMPLE): > It is recommended that applications use INSERT with ON CONFLICT DO UPDATE rather than actually using this pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why don't we have the same kind of issue with addOrUpdatePeer
?
eclair-core/src/main/scala/fr/acinq/eclair/db/pg/PgChannelsDb.scala
Outdated
Show resolved
Hide resolved
We probably do! Will do a pass on all other db calls. |
Done with bb93ee5. |
Codecov Report
@@ Coverage Diff @@
## master #1762 +/- ##
==========================================
+ Coverage 89.17% 89.24% +0.07%
==========================================
Files 143 143
Lines 10772 10768 -4
Branches 477 464 -13
==========================================
+ Hits 9606 9610 +4
+ Misses 1166 1158 -8
|
The upsert pattern in
channelsDb.addOrUpdateChannel
is apparently not compatible with concurrent transactions when they are inSERIALIZABLE
mode.A simple test shows the issue and the following exception is thrown:
I tried reducing the isolation level, but 1) I'm not sure what the consequences are in terms of locking the db and 2) it didn't entirely fix the issue.
As per the postgres doc, the recommended construct for the upsert pattern is with the
ON CONFLICT
clause:I'm not sure about the performance of this (we mostly do updates, so we will run into the
ON CONFLICT
a lot), but let's first make it work.