public inbox for [email protected]  

help / color / mirror / Atom feed

From: James Pang <[email protected]>
To: [email protected]
To: Laurenz Albe <[email protected]>
Subject: Re: cached plan must not change result type
Date: Fri, 29 Mar 2024 17:08:44 +0800
Message-ID: <CAHgTRfeXGN9d7vgg8LtwpNYw_+f-zmMYsOc1U9rhXkGcwWtNng@mail.gmail.com> (raw)
In-Reply-To: <CAHgTRfe+REHqYoQJ_ykj_p416PbdHz+UN06-R3PVr6auMx4w2g@mail.gmail.com>
References: <CAHgTRfcg2jGnjSqq1NVuMDtCjRU3aOXWrhXn1L=92Ka_Ug6euw@mail.gmail.com>
	<[email protected]>
	<CAHgTRfe+REHqYoQJ_ykj_p416PbdHz+UN06-R3PVr6auMx4w2g@mail.gmail.com>

 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 <[email protected]> 於 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 <[email protected]> 於 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
>>
>

view thread (13+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: cached plan must not change result type
  In-Reply-To: <CAHgTRfeXGN9d7vgg8LtwpNYw_+f-zmMYsOc1U9rhXkGcwWtNng@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox