[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: "cache lookup failed for type ####" when running unit tests
From:       Wilhansen Li <willi.t1 () gmail ! com>
Date:       2018-08-29 6:51:09
Message-ID: CAD57gzDYvUNB_L6j_sQnfE5uOFLjyU_uvgpG2aDSm_7Cf_JiOw () mail ! gmail ! com
[Download RAW message or body]

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
>

[Attachment #3 (text/html)]

<div dir="ltr">Hi Tom,<div><br></div><div>Apologies for not giving more context/code \
however, your analysis is right on the spot. Thanks for the \
hint!</div><div><br></div><div>I ended up closing and re-opening the connection \
between fixtures instead of persisting them which is what was happening before. While \
it doesn&#39;t fix the root cause of the issue (it&#39;s in the JDBC driver side \
after all, not something I want to touch), it suffices for our use \
case.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 27, 2018 at \
2:39 AM Tom Lane &lt;<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">Wilhansen Li &lt;<a \
href="mailto:willi.t1@gmail.com" target="_blank">willi.t1@gmail.com</a>&gt; \
writes:<br> &gt; I have a web application with a bunch of unit tests which involve \
accessing<br> &gt; a PostgreSQL database. My schema contains composite types and \
stored<br> &gt; procedures.<br>
<br>
&gt; When running the tests, I&#39;m getting a<br>
&gt; &quot;com.impossibl.postgres.jdbc.PGSQLSimpleException: cache lookup failed \
for<br> &gt; type 64790&quot; when trying to call a stored procedure whose parameter \
is an<br> &gt; array of a composite type (e.g. &quot;create function foo(param \
comp_type[]&quot;)<br> <br>
&gt; The funny thing is, when I run the specific test in isolation the problem<br>
&gt; disappears.<br>
<br>
Hard to be sure when you haven&#39;t shown us any code, but I suspect the<br>
issue boils down to caching of type data inside a plpgsql function that<br>
*uses* some type you dropped and recreated, without having any parameter<br>
of that type.   (If it did have such a parameter, you&#39;d have been forced<br>
to drop and recreate the function, eliminating the cached info.   That<br>
doesn&#39;t apply though to internal uses, such as a variable of the type.)<br>
<br>
Another possibility, if you&#39;re trying to pass an argument of such a type<br>
directly from the client side, is that the JDBC driver is caching data<br>
about that type name and doesn&#39;t realize you&#39;ve replaced it with some<br>
new definition.<br>
<br>
                                    regards, tom lane<br>
</blockquote></div>



[prev in list] [next in list] [prev in thread] [next in thread]