Postgrex: cryptic warning message

Questions & Help Questions
, , ,
1

Hey everybody, in our CI we regularly get this message while MIX_ENV=test mix ecto.migrate is executing:

%Postgrex.Query{columns: nil, name: “ecto_512389”, param_formats: nil, param_oids: nil, param_types: nil, ref: reference<0.3268973948.3458203652.198652>, result_formats: nil, result_oids: nil, result_types: nil, statement: “stripped”, types: nil} uses unknown oid 20031 causing bootstrap

(The statement above is an UPDATE with a condition.)

I also regularly get the message when I drop and re-create my local test DB and then run migrations on it.

I poked around the net but the idea of Postgres OIDs doesn’t seem to apply to our app at all. I grep-ed all our migrations but couldn’t find anything about OIDs either.

Anybody has an idea? It’s a warning that doesn’t break anything but since it occurs regularly, it piqued my interest.

2

Not sure if you’ve seen it in your searches already but the postgrex readme has some discussion about their use of oids and some considerations around ints that might be relevant?

3

I did, but it says absolutely nothing to me. The only thing OID-related to our DB is the fact that PG still gives OIDs to our tables (automatically) but we haven’t configured any table to use OIDs inside them.

4

Any way you can post the contents of statement with maybe the data stripped but the query intact?

5

Come to think of it, it’s not something compromising anyway:

UPDATE "debits" AS d0 SET "counterparty" = $1 WHERE (d0."type" = ‘customer_charge_recoupment’)

6

Any chance you have migrations or anything changing the DB schema running as you run your suite?

7

It’s possible. There are quite a few of them and I am not quite caught up with them just yet.

For now I am aware that we add, remove and add values to enums on several places. No materialized views or views of any kind. No stored procedures.

8

That may be the root cause. If you change the database structure, then whatever Postgres has cached will fail. But this should only happen if they are changed while the suite runs.

9

I am not excluding possible races. I happen to see the message only while migrating a freshly created test DB though, not during mix test. (Not sure if you implied that by saying “suite”.)

Is the error message serious? I honestly can’t say even after searching for PG OIDs for a while.

10

Right, so it is happening because you are doing queries while you run your migrations. So Postgrex needs to update the cached data as it goes.

11

Does that mean that Postgrex is simply rebooting its supervision tree? Because if it caches types as a performance optimization technique, I am guessing it will have to reboot something after they change?

12

More like updating the state of multiple connections. I believe everything happens without restarting the tree.

13

I see. So this is a warning message, not an error condition.