-
Notifications
You must be signed in to change notification settings - Fork 419
RuntimeError: no decoder for OID 3910 #278
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
Comments
It appears that the codec cache is still racy :-( I'll look into this soon. |
elprans
added a commit
that referenced
this issue
May 31, 2018
Current global type codec cache works poorly in a pooled environment. The global nature of the cache makes introspection/cache bust race a frequent occurrence. Additionally, busting the codec cache in _all_ connections only because one of them had reconfigured a codec seems wrong. The fix is simple: every connection now has its own codec cache. The downside is that there will be more introspection queries on fresh connections, but given that most connections in the field are pooled, the robustness gains are more important. Fixes: #278
elprans
added a commit
that referenced
this issue
May 31, 2018
Current global type codec cache works poorly in a pooled environment. The global nature of the cache makes introspection/cache bust race a frequent occurrence. Additionally, busting the codec cache in _all_ connections only because one of them had reconfigured a codec seems wrong. The fix is simple: every connection now has its own codec cache. The downside is that there will be more introspection queries on fresh connections, but given that most connections in the field are pooled, the robustness gains are more important. Fixes: #278
elprans
added a commit
that referenced
this issue
Jun 1, 2018
Current global type codec cache works poorly in a pooled environment. The global nature of the cache makes introspection/cache bust race a frequent occurrence. Additionally, busting the codec cache in _all_ connections only because one of them had reconfigured a codec seems wrong. The fix is simple: every connection now has its own codec cache. The downside is that there will be more introspection queries on fresh connections, but given that most connections in the field are pooled, the robustness gains are more important. Fixes: #278
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
python:3.6
running on AWS ECS (prod); local venv install on macOS (dev).uvloop? We use uvloop, definitely happening there. Haven't tried vanilla asyncio.
What's happening
We are experiencing intermittent
RuntimeError
s with the messageno decoder for OID 3910
. This appears to be similar to #122, #133, and #241.Per Postgres'
pg_type.h
, 3910 is the OID for the typetstzrange
.It's not happening constantly – only a couple of times in the last 24 hours – but it is happening. I've provided a bunch of detail below but please let me know if I can add anything else to help track this down.
Environment details
The schema we are using is as follows:
And the query that's raising this error every once in a while:
In this query,
$1
is a point representing the user's reported location and$2
is a "fudge factor" in meters.Usage notes
All of our application's interactions with Postgres are wrapped in transactions using this async context manager:
In practice it looks like this:
The method below, which calls
set_type_codec
a few times, is passed as theinit
kwarg toasyncpg.create_pool()
. This is called lazily by ourPostgres
class, the first time.get_pool()
is called. Subsequent calls toPostgres.get_pool()
return this singleton pool.The text was updated successfully, but these errors were encountered: