Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rq1dH-00A8jo-My for pgsql-admin@arkaria.postgresql.org; Fri, 29 Mar 2024 02:06:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rq1dF-008XKA-J9 for pgsql-admin@arkaria.postgresql.org; Fri, 29 Mar 2024 02:06:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rq1dF-008XK2-8O for pgsql-admin@lists.postgresql.org; Fri, 29 Mar 2024 02:06:13 +0000 Received: from mail-oo1-xc31.google.com ([2607:f8b0:4864:20::c31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rq1dB-006yfB-93 for pgsql-admin@lists.postgresql.org; Fri, 29 Mar 2024 02:06:11 +0000 Received: by mail-oo1-xc31.google.com with SMTP id 006d021491bc7-5a492093073so685280eaf.0 for ; Thu, 28 Mar 2024 19:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711677969; x=1712282769; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=EGzLSIWJk6VfHlE6kJ6xGuLmmQJiQvtHs6md4JpQnHo=; b=TOfO2T2Mi3c8MdtSlWWW+V4YTTylcYObLdVEnDiFQVCL8LKyP8+DlI9ChAccBZhjSS M9DIEkrpYxPTeMlIsGhKCz11sYOohR5Sw6VJYpnFdP+5oKhy46w/pvZWXgXYhILvEWpY AfFvCtjAHPhvQXKkOK/o12M0ubcM9ZNmWsoHGDyTS8oKO78Vdg7hkwiFICeWp3IeonLk sbZiPsh7kkOIdhPyc/XWN2CYfu73gKbEoDIFnbIN205aUXS5Tl+kikkwozx9o4/GOgyv kLYMF+iMIq+IDCHYYD1dz1kz/dReDttf7x/c0a1ej6LVcGnVnOrEB/3fCML3IA+I5L0P 2e/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711677969; x=1712282769; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=EGzLSIWJk6VfHlE6kJ6xGuLmmQJiQvtHs6md4JpQnHo=; b=L7Ko9nsCflcVqe7D121/hbj49JosFLp0U3QzbJmsagsqXHLkoivMh45cWE3/XFt9ah f9nSmD+NO+gab9TYXNLcLxkpqG2egfURVHgwWHyEhVme39R3G7tAGJ7JqCvZwBL6wU81 lFTA5IxqQ16pvjG/269ILqlZS+vpYRuga5Epjf9X5J18yOKQi8jk3Dzg+Gxdp7Tk6rsJ s5Mg9QZF5ss+IYVLs7/fwi3QsNO6Gd5H/Civngwip4cnyPNmZXHwlt+Xpej3XFwrbIoS j6LB98A4isiB33E5HfoDXMtS4kA1edRcq9M5moYl7ASPWUobP/ahTvf1oyE/SvIy1lme qV0w== X-Gm-Message-State: AOJu0YwYbkKCrv6BoC9zZPmcR/55SsKjLwHhYETEf57pNfstgcS2RbSl /G+AcCF3XZc/uJXmXsCjmRCau/wQifbpR3tk5myHtXy47AummegRxM/uw3EsoT+8iZnUIrSng+v 3jS040AyL1jC0k/C1Vnqa4NgpI8gJw1EUUco= X-Google-Smtp-Source: AGHT+IH453+vgyW86CVOVZjODpiRmRw8s13lSDh3TfmdegrWNzwCvzbEfJWktmga2ZA7XrDg4Br96EQH7YQ2Act9FV0= X-Received: by 2002:a05:6871:110:b0:22a:aeaa:e4a0 with SMTP id y16-20020a056871011000b0022aaeaae4a0mr1169891oab.8.1711677969150; Thu, 28 Mar 2024 19:06:09 -0700 (PDT) MIME-Version: 1.0 From: James Pang Date: Fri, 29 Mar 2024 10:05:59 +0800 Message-ID: Subject: cached plan must not change result type To: pgsql-admin@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000523b060614c3154c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000523b060614c3154c Content-Type: text/plain; charset="UTF-8" hi, 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? How to avoid this issue when DDL schema changes ? Thanks, James --000000000000523b060614c3154c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hi,
=C2=A0 =C2=A0PGV14, client use PGJDBC driver and p= repared statements, when a table "alter table alter column type ...&qu= ot; changes done, a lot of JDBC clients got this error "cached plan mu= st not change result type".=C2=A0 when a JDBC client got this error fi= rst time after the DDL schema change, JDBC driver will clear this caching-p= lan and following same SQL statement got parsing again and new cached plan = right?=C2=A0=C2=A0
=C2=A0 How to avoid this issue when DDL schema= changes ?=C2=A0

Thanks,

= James
--000000000000523b060614c3154c--