From: | James Pang <jamespang886(at)gmail(dot)com> |
---|---|
To: | pgsql-jdbc(at)lists(dot)postgresql(dot)org, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Subject: | Re: cached plan must not change result type |
Date: | 2024-03-29 09:08:44 |
Message-ID: | CAHgTRfeXGN9d7vgg8LtwpNYw_+f-zmMYsOc1U9rhXkGcwWtNng@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-jdbc |
forwarded to pgjdbc, we want to understand why JDBC failed to reexecute
the SQL instead of throw error out. Like this document
https://jdbc.postgresql.org/documentation/server-prepare/#re-execution-of-failed-statements
.
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
James Pang <jamespang886(at)gmail(dot)com> 於 2024年3月29日週五 下午4:56寫道:
> Thanks Laurenz, forwarded to pgjdbc, we want to understand why JDBC
> failed to reexecute the SQL instead of throw error out. Like this document
> https://jdbc.postgresql.org/documentation/server-prepare/#re-execution-of-failed-statements
> .
>
>
>
> Thanks,
>
>
>
> James
>
> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> 於 2024年3月29日週五 下午4:40寫道:
>
>> 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
>>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2024-03-29 15:45:09 | Re: cached plan must not change result type |
Previous Message | James Pang | 2024-03-29 08:56:31 | Re: cached plan must not change result type |
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2024-03-29 15:45:09 | Re: cached plan must not change result type |
Previous Message | James Pang | 2024-03-29 08:56:31 | Re: cached plan must not change result type |