protected final void execute(CachedQuery cachedQuery,
@Nullable ParameterList queryParameters, int flags)
throws SQLException {
try {
executeInternal(cachedQuery, queryParameters, flags);
} catch (SQLException e) {
// Don't retry composite queries as it might get partially executed
if (cachedQuery.query.getSubqueries() != null <<< no idea how this cachedQuery.query.getSubqueries() != null
|| !connection.getQueryExecutor().willHealOnRetry(e)) {
throw e;
}
cachedQuery.query.close();
// Execute the query one more time
executeInternal(cachedQuery, queryParameters, flags);
}
}
cachedQuery.query.getSubqueries() != null, how this code decide composite queries here ? that mean some query having subquery or having many JOIN or LEFT JOINs like select .... A left join B ...
Thanks,
James
On Fri, 2024-03-29 at 10:05 +0800, James Pang wrote:
> PGV14, client use PGJDBC driver and prepared statements, when a table
> "alter table alter column type ..." changes done, a lot of JDBC clients
> got this error "cached plan must not change result type". when a JDBC
> client got this error first time after the DDL schema change, JDBC driver
> will clear this caching-plan and following same SQL statement got parsing
> again and new cached plan right?
Not sure; what do you observe?
Anyway, this is a known problem:
https://jdbc.postgresql.org/documentation/server-prepare/#ddl
> How to avoid this issue when DDL schema changes ?
Don't use server-side prepared statements:
https://jdbc.postgresql.org/documentation/server-prepare/#deactivation
You'll lose some performance though.
Questions like this had better be asked on the pgsql-jdbc list.
Yours,
Laurenz Albe