nhpip
Hi,
We are using DBConnection and Ecto with a Postgres DB. Occasionally we get errors like below in the Postgres log:
2022-09-17 12:36:59.478 EDT [92184] ERROR: could not serialize access due to concurrent update
2022-09-17 12:36:59.478 EDT [92184] CONTEXT: SQL statement "update collections
set scoped_seq = scoped_seq + 1
where id = collection_id
returning scoped_seq"
PL/pgSQL function advance_seq(uuid) line 5 at SQL statement
SQL statement "select advance_seq(new.collection_id)"
PL/pgSQL function set_rev_id() line 3 at SQL statement
90% of the time this results in a Postgrex.Error exception with a code of :serialization_failure which permits us to retry the transaction.
However, in a small percentage of cases we get the same error in the Postgres log, but instead a DBConnection.ConnectionError exception with a message of:
12:17:13.217 [error] Postgrex.Protocol (#PID<0.2447.0>) disconnected: ** (DBConnection.ConnectionError) transaction rolling back
My questions are:
- Why do we sometimes get a Postgrex error and sometimes a DBConnection disconnect for what appears to be the same error?
- Why should it disconnect?
- Can we stop it from disconnecting (or force a reconnect)?
Now I can retry the transaction further up the stack, but that involves re-doing lots of data processing and doesn’t always work.
We are running latest of db_connection, ecto and postgrex.
Thanks
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #security
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 2- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
joey_the_snake
In general
Postgrex.Errormeans your query went through to the database and the response from the database was an error.DBConnection.Errorthere wasn’t a clean send/receive to/from the db.In your case it looks like that error comes when you try to execute a query on a transaction that is already rolling back. So this puts the connection in an erroneous state and it raises/disconnects.
A wild guess: you are retrying in the same transaction you receive the error in instead of letting the transaction completely roll back and starting a new one.
nhpip
Thanks, that makes total sense. It was before my time, but the implementation is kind of weird. The pseudo code looks like:
Now the problem is that
mod,funcan also invokeServer.transaction, with a differentmod,fun. Indeed it can get quite deep. So it’s possible that the exception can get caught and repeated in an inner layer.Thanks again…