Re: [JDBC] Error 'Received resultset tuples, but no field structurefor them' on queries subsequent to an error

Hello Christina,

On Wed, 2017-11-15 at 17:24 +0000, Christina Simpson wrote:
> Hi. I am working through an upgrade of JDBC drivers to version
> 42.1.4. After the upgrade we were getting the following error in one
> of our tests. It was only occurring when several tests were run
> together and running the failing test by itself passed.
>  
> The error is:
>  
> java.lang.IllegalStateException: Received resultset tuples, but no
> field structure for them
>             at
> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutor
> Impl.java:2121)
>             at
> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.ja
> va:300)
>             at
> org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
>             at
> org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
>             at
> org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedSt
> atement.java:169)
>             at
> org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatem
> ent.java:117)
>             at
> com.zaxxer.hikari.pool.ProxyPreparedStatement.executeQuery(ProxyPrepa
> redStatement.java:52)
>             at
> com.zaxxer.hikari.pool.HikariProxyPreparedStatement.executeQuery(Hika
> riProxyPreparedStatement.java)
>             at
> org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(Jd
> bcTemplate.java:692)
>             at
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:
> 633)
>             at
> org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:68
> 4)
>             at
> org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:71
> 1)
>             at
> org.springframework.jdbc.core.namedparam.NamedParameterJdbcTemplate.q
> uery(NamedParameterJdbcTemplate.java:154)
>  
> I’ve been able to simplify the test failures with some possibly
> interesting results and have narrowed down the failure to use a
> single select query that contains a UUID (it is cast as a uuid in the
> query) but we are passing to spring jdbc template as a string. If
> exactly the fifth query contains an invalid uuid, the query fails as
> expected with this stack
>  
> Caused by: org.postgresql.util.PSQLException: ERROR: invalid input
> syntax for uuid: "0b74c00c"
>             at
> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryEx
> ecutorImpl.java:2477)
>             at
> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutor
> Impl.java:2190)
>             at
> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.ja
> va:300)
>             at
> org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
>             at
> org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
>             at
> org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedSt
> atement.java:169)
>             at
> org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatem
> ent.java:117)
>             at
> com.zaxxer.hikari.pool.ProxyPreparedStatement.executeQuery(ProxyPrepa
> redStatement.java:52)
>             at
> com.zaxxer.hikari.pool.HikariProxyPreparedStatement.executeQuery(Hika
> riProxyPreparedStatement.java)
>             at
> org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(Jd
> bcTemplate.java:692)
>             at
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:
> 633)
>  
> I can trace through with the debugger and see that after the query
> fails, the cached statement is added back to the statement cache and
> the value for fields is reset to null.
>  
> It looks to be set to null in this method
> org.postgresql.core.v3.QueryExecutorImpl#sendParse
>  
> The next query to take that query out of the cache fails with the
> first error above. At first I thought it was extremely odd that this
> had to be exactly the fifth query but as I was debugging I noticed
> that at the value of prepareThreshold is 5.
>  
> This is smelling like a possible bug but I wanted to check with the
> experts. I can attempt to provide some more simplified code sample if
> needed but am hoping it may be easily reproduced with this report. I
> haven’t seen this error reported exactly like this but have seen some
> reports of people reporting this error then reporting that it just
> went away. Which might make sense if failed queries are getting
> released to the query cache and the fields values are reset but never
> set again but once that query falls off the LRU cache the problem
> goes away. I haven’t been able to find a work around yet but would
> love suggestions to try. Thanks.



I am not an expert.

There are extensive notes about this from Craig Ringer on github.
You haven't supplied the code around the prepareStatement that you are
using.
It seems that if you supply a different data type to one of the
parameters than what it was expecting from a previous use of the
prepared statement, it loses the meta data. So, it can't handle the
result set appropriately. As you appear to be running in a multi-
threaded environment my hypothesis is the same prepared statement is
being used in two different threads but in one thread a certain column
is treated as say integer, and in the other thread that column is
treated as say string. Hence the intermittent failure.
The server parsed the prepared statement once but it is being used by
multiple instances at a given point in time.
My only suggestion is to give your prepared statements an unique
"name".
I'm sorry but I can't test this at the moment.

HTH,
Rob


-- 
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc