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 <t...@sss.pgh.pa.us> wrote: > Wilhansen Li <willi...@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 >
