"cache lookup failed for type ####" when running unit tests
Hi all,
I have a web application with a bunch of unit tests which involve accessing
a PostgreSQL database. My schema contains composite types and stored
procedures.
When running the tests, I'm getting a
"com.impossibl.postgres.jdbc.PGSQLSimpleException: cache lookup failed for
type 64790" when trying to call a stored procedure whose parameter is an
array of a composite type (e.g. "create function foo(param comp_type[]")
The funny thing is, when I run the specific test in isolation the problem
disappears.
Note that the tests are grouped into fixtures and each fixture resets the
database when run (it drops all tables, types, and functions then recreates
them) and they are run serially (so it's not a parallel execution problem).
Also, each test is run inside a transaction that's set to rollback after
the test is finished in order to reduce the amount database resets.
I'm having problems understanding what's causing the problem but i suspect
that the rapid database resets paired with transaction use (abuse?) are the
ones causing it. I've tried delays but those don't fix the problems.
Wilhansen Li <willi.t1@gmail.com> writes:
I have a web application with a bunch of unit tests which involve accessing
a PostgreSQL database. My schema contains composite types and stored
procedures.
When running the tests, I'm getting a
"com.impossibl.postgres.jdbc.PGSQLSimpleException: cache lookup failed for
type 64790" when trying to call a stored procedure whose parameter is an
array of a composite type (e.g. "create function foo(param comp_type[]")
The funny thing is, when I run the specific test in isolation the problem
disappears.
Hard to be sure when you haven't shown us any code, but I suspect the
issue boils down to caching of type data inside a plpgsql function that
*uses* some type you dropped and recreated, without having any parameter
of that type. (If it did have such a parameter, you'd have been forced
to drop and recreate the function, eliminating the cached info. That
doesn't apply though to internal uses, such as a variable of the type.)
Another possibility, if you're trying to pass an argument of such a type
directly from the client side, is that the JDBC driver is caching data
about that type name and doesn't realize you've replaced it with some
new definition.
regards, tom lane
Hi Tom,
Apologies for not giving more context/code however, your analysis is right
on the spot. Thanks for the hint!
I ended up closing and re-opening the connection between fixtures instead
of persisting them which is what was happening before. While it doesn't fix
the root cause of the issue (it's in the JDBC driver side after all, not
something I want to touch), it suffices for our use case.
On Mon, Aug 27, 2018 at 2:39 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Show quoted text
Wilhansen Li <willi.t1@gmail.com> writes:
I have a web application with a bunch of unit tests which involve
accessing
a PostgreSQL database. My schema contains composite types and stored
procedures.When running the tests, I'm getting a
"com.impossibl.postgres.jdbc.PGSQLSimpleException: cache lookup failedfor
type 64790" when trying to call a stored procedure whose parameter is an
array of a composite type (e.g. "create function foo(param comp_type[]")The funny thing is, when I run the specific test in isolation the problem
disappears.Hard to be sure when you haven't shown us any code, but I suspect the
issue boils down to caching of type data inside a plpgsql function that
*uses* some type you dropped and recreated, without having any parameter
of that type. (If it did have such a parameter, you'd have been forced
to drop and recreate the function, eliminating the cached info. That
doesn't apply though to internal uses, such as a variable of the type.)Another possibility, if you're trying to pass an argument of such a type
directly from the client side, is that the JDBC driver is caching data
about that type name and doesn't realize you've replaced it with some
new definition.regards, tom lane