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 1qY8qY-000tIv-1j for pgsql-jdbc@arkaria.postgresql.org; Mon, 21 Aug 2023 17:37:46 +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 1qY8qW-008vvY-3E for pgsql-jdbc@arkaria.postgresql.org; Mon, 21 Aug 2023 17:37:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qY8qV-008vvE-RE for pgsql-jdbc@lists.postgresql.org; Mon, 21 Aug 2023 17:37:43 +0000 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qY8qQ-000DCA-ER for pgsql-jdbc@lists.postgresql.org; Mon, 21 Aug 2023 17:37:43 +0000 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2bb97f2c99cso57783621fa.0 for ; Mon, 21 Aug 2023 10:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692639457; x=1693244257; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SVlslyhkgnhxLKLH7YXiixhZM58dwfsXoGnNF1gm9iM=; b=rTI/ywt+h/Hwh4VfIu6SBFuDWEMXU0g3Ly74E6rAEB3dq6N9gW9EAgl6Uupn+r/abf t7h6oAfcBD0hyoN/+/rTMa8Y0QQ1t/AHTi0KcuJN+SjMAvuR8vG15sAWa/VUmMferTGW xY6TmOE0qtvTmM237HoOgZKqlUnlcqyeO5OH2ra+bMvqjdiVGeLoMVsBgy+jFBRudw7X dAxOkUYAOaZDavFcUZcWN8M4dTLQvMXpxAYCcUlKSCyQveWU3OMjtZValCdhQXYdFN6k 2553csICsyowCP9t0ImSMLcE2Yk+0yxQp49LeOq6kiZ9kf1FU6gcE/4G5EN4/64N01y+ Q/GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692639457; x=1693244257; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SVlslyhkgnhxLKLH7YXiixhZM58dwfsXoGnNF1gm9iM=; b=SgrA2r4Jn72AC9WnUswD1Ju8swDF2uYMRNB5MyJQFn/KvVzHRwR5tL9ziLi7b2469z Eg7ejBSBi9YMe8eN0XYqkdrHC66fbRXL70uzLRfdHsb6z/GBCoJfN4gKuCvcFFFHvc0u Pwe/O75nPc1k32kuIv2n26TkBJJ4xRD+RjYwJF9jAFx0coRvwbHIprzoBCoiQubZ7wV0 E2oZzF2fiVVWJEqdYd+fYXYTH/4IfFLGT57IGv9bhYcoDJBCqUou3LcvLta9WrqU3ehO 37P9im9jhhJiTLcz+3e8I5VWk+SchrU5dYXTLBrBOGqebB3nrtk+2dzHrJdLplcRKA7Y f1LA== X-Gm-Message-State: AOJu0Yz8gnzdJ3PGRLwOw6XPT7H2IJo5o0WsLYGAS2hDfHFAoeGaYCNG nPaxbPudgMVz7PFNe+UHac1FEpDHuobOzN/iZFYxXZum+8Q= X-Google-Smtp-Source: AGHT+IGtY0G8luGFKUgxE+GFpRsxpLKVyR9PI6uMWxa0sALZ8d3nPTBVbNUxGvhKWfATBK6FDDm9MNIsC6vrNNIP/HQ= X-Received: by 2002:a2e:99ce:0:b0:2bc:b27f:4019 with SMTP id l14-20020a2e99ce000000b002bcb27f4019mr3961353ljj.6.1692639456520; Mon, 21 Aug 2023 10:37:36 -0700 (PDT) MIME-Version: 1.0 From: Edoardo Panfili Date: Mon, 21 Aug 2023 19:37:25 +0200 Message-ID: Subject: The same prepared query yield "-1" the first six times and then "-1.0" To: pgsql-jdbc@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hy, I posted this topic in pgsql-general and they say that maybe it is better to ask in psql-jdbc so... I am using postgresql version: 15.3 (Debian 15.3-0+deb12u1) org.postgresql.postgresql JDBC driver version: 42.6.0 via Java 17.0.7 I discovered an unattended (for me) situation: when I execute 10 times the same prepared query the result is not always the same. I wrote a little test case to show this. this is the db that I am using: CREATE TABLE number( name character varying(30) NOT NULL, dim1 real DEFAULT '-1' NOT NULL ); insert into number (name) VALUES('first'); and the test program: static final String DB_URL =3D "jdbc:postgresql://192.168.64.7:5432/testdb"= ; static final String USER =3D "user"; static final String PASS =3D "password"; public static void main(String[] args) throws Exception { Connection conn =3D DriverManager.getConnection(DB_URL, USER, PASS); for(int i=3D0; i<10; i++) { try( PreparedStatement istruzioneCelle =3D conn.prepareStatement( "SELECT dim1 FROM number WHERE name=3D'first'") ) { ResultSet rs =3D istruzioneCelle.executeQuery(); rs.next(); System.out.print("p: "+rs.getString("dim1")+"\n=E2=80=9D); } catch (SQLException e) { e.printStackTrace(); } } conn.close(); } The attended result was a sequence of ten equal values but this is the actual result: p: -1 p: -1 p: -1 p: -1 p: -1 p: -1.0 p: -1.0 p: -1.0 p: -1.0 p: -1.0 Semantically the same but not the representation. All works fine if I open and close the connection after every single query but in production I am using pooled connections. This is what I can read in postgresql logs (it seems that after 4 queries the statement becomes named and the result changes after the second call to the named query): 2023-08-21 11:51:50.633 CEST [1511] user@testdb LOG: execute : SET extra_float_digits =3D 3 2023-08-21 11:51:50.634 CEST [1511] user@testdb LOG: execute : SET application_name =3D 'PostgreSQL JDBC Driver' 2023-08-21 11:51:50.644 CEST [1511] user@testdb LOG: execute : SELECT dim1 FROM number WHERE name=3D'first' 2023-08-21 11:51:50.648 CEST [1511] user@testdb LOG: execute : SELECT dim1 FROM number WHERE name=3D'first' 2023-08-21 11:51:50.649 CEST [1511] user@testdb LOG: execute : SELECT dim1 FROM number WHERE name=3D'first' 2023-08-21 11:51:50.650 CEST [1511] user@testdb LOG: execute : SELECT dim1 FROM number WHERE name=3D'first' 2023-08-21 11:51:50.651 CEST [1511] user@testdb LOG: execute S_1: SELECT dim1 FROM number WHERE name=3D'first' 2023-08-21 11:51:50.651 CEST [1511] user@testdb LOG: execute S_1: SELECT dim1 FROM number WHERE name=3D'first' 2023-08-21 11:51:50.653 CEST [1511] user@testdb LOG: execute S_1: SELECT dim1 FROM number WHERE name=3D'first' 2023-08-21 11:51:50.653 CEST [1511] user@testdb LOG: execute S_1: SELECT dim1 FROM number WHERE name=3D'first' 2023-08-21 11:51:50.654 CEST [1511] user@testdb LOG: execute S_1: SELECT dim1 FROM number WHERE name=3D'first' 2023-08-21 11:51:50.656 CEST [1511] user@testdb LOG: execute S_1: SELECT dim1 FROM number WHERE name=3D=E2=80=98first' Can I do something to avoid this problem? thank you Edoardo