Re: Error 'Received resultset tuples, but no field structure for them' on queries subsequent to an error

Christina,

The fact that it happens on the 5th is important. I would like to see the
query or a query like it that causes the problems

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com

On 15 November 2017 at 19:30, rob stone <floriparob(at)gmail(dot)com> wrote:

> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>