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.
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