Обсуждение: "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:
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