elixir-ecto/postgrex

Postgrex.QueryError type `citext` can not be handled by the types module Postgrex.DefaultTypes

adampash opened this issue · 7 comments

I've been running into this issue sporadically in my codebase. I'm using the citext extension, installed on the public schema, and probably one time out of every 20 or so runs of my Phoenix app, I'll get this error when querying a field with citext type.

 ** (exit) an exception was raised:
     ** (Postgrex.QueryError) type `citext` can not be handled by the types module Postgrex.DefaultTypes
         (ecto_sql 3.7.1) lib/ecto/adapters/sql.ex:760: Ecto.Adapters.SQL.raise_sql_call_error/1
         (ecto_sql 3.7.1) lib/ecto/adapters/sql.ex:693: Ecto.Adapters.SQL.execute/5
         (ecto 3.7.1) lib/ecto/repo/queryable.ex:219: Ecto.Repo.Queryable.execute/4
         (ecto 3.7.1) lib/ecto/repo/queryable.ex:19: Ecto.Repo.Queryable.all/3
         (elixir 1.12.3) lib/enum.ex:1582: Enum."-map/2-lists^map/1-0-"/2
         (dataloader 1.0.10) lib/dataloader/ecto.ex:695: Dataloader.Source.Dataloader.Ecto.run_batch/2
         (elixir 1.12.3) lib/enum.ex:1582: Enum."-map/2-lists^map/1-0-"/2
         (dataloader 1.0.10) lib/dataloader/ecto.ex:635: Dataloader.Source.Dataloader.Ecto.run_batches/1
         (dataloader 1.0.10) lib/dataloader/ecto.ex:400: Dataloader.Source.Dataloader.Ecto.run/1
         (dataloader 1.0.10) lib/dataloader.ex:148: anonymous fn/1 in Dataloader.run/1
         (elixir 1.12.3) lib/enum.ex:1586: anonymous fn/3 in Enum.map/2
         (stdlib 3.16.1) maps.erl:410: :maps.fold_1/3
         (elixir 1.12.3) lib/enum.ex:2397: Enum.map/2
         (dataloader 1.0.10) lib/dataloader.ex:168: Dataloader.run/1
         (absinthe 1.6.6) lib/absinthe/middleware/dataloader.ex:10: Absinthe.Middleware.Dataloader.before_resolution/1
         (elixir 1.12.3) lib/enum.ex:2385: Enum."-reduce/3-lists^foldl/2-0-"/3
         (absinthe 1.6.6) lib/absinthe/phase/document/execution/resolution.ex:49: Absinthe.Phase.Document.Execution.Resolution.perform_resolution/3

The error will persist for that run of the server; if I restart the server, it works fine. (It reproduces locally and deployed, with about the same consistency — one out of every 20 or so runs.)

I've seen this issue, but that doesn't look like the same problem I'm having. Like I said, most of the time, it runs without issue.

Any ideas what might be happening here? Happy to provide more information.

What is your pool size? And what is the Erlang/OTP version? Unfortunately nothing immediately comes to mind, besides a lower-level bug. So I would make sure to be running on the most recent patch version of OTP and play with the pool size to see if the issue is related to the pool size. If it still persists, then I would try to isolate it in a reproducible case so we can take a look.

Thanks for the response!

What is your pool size? And what is the Erlang/OTP version?

Pool size is 10. Erlang/OTP 24. Will see if I get a repo/test case to reproduce.

@josevalim I haven't yet been able to set up a reproducible test case, but I was able to do some debugging on the codebase where I'm seeing the issue. When the error does show up, the Postgrex.TypeInfo struct for the citext type looks like (note the public namespace on input, output, receive, and send):

%Postgrex.TypeInfo{
  array_elem: 0,
  base_type: 0,
  comp_elems: [],
  input: "public.citextin",
  oid: 1030709,
  output: "public.citextout",
  receive: "public.citextrecv",
  send: "public.citextsend",
  type: "citext"
}

When it's working normally/without errors, the type info looks like:

%Postgrex.TypeInfo{
  array_elem: 0,
  base_type: 0,
  comp_elems: [],
  input: "citextin",
  oid: 1030709,
  output: "citextout",
  receive: "citextrecv",
  send: "citextsend",
  type: "citext"
}

If it's at all relevant, I'm using a non-default schema namespace (that is, the schema is not the public postgres schema) in the app where I'm seeing this behavior.

Hrm. I think it is documented that we require extensions to be installed on all schemas. Could that be the root cause? But I thought that the type information is shared across all connections, so that wouldn’t explain you getting different query results unless you have different repos?

Ahhh okay maybe that's at the root of it? I have two different Ecto repos set up in this project for the same database — they use different credentials and have different levels of access to tables in the database. Could that cause this?

The separate repos should not be a problem. My point is that 100% of the citext queries might fail in one of those repos. You just need to find out which one. :)

Thanks so much for the help, @josevalim. I'm going to close this while I see if I can narrow things down; if I do isolate a problem that's more than just my code, I'll update.