Message-ID: From: "vlsi (@vlsi)" To: "pgjdbc/pgjdbc" Date: Mon, 26 Aug 2024 12:21:14 +0000 Subject: Re: [pgjdbc/pgjdbc] issue #3365: EOFException on PreparedStatement#toString with unset bytea parameter since 42.7.4 In-Reply-To: References: List-Id: X-GitHub-Author-Login: vlsi X-GitHub-Comment-Id: 2310076231 X-GitHub-Comment-Type: issue_comment X-GitHub-Edited-At: 2024-08-26T12:23:23Z X-GitHub-Issue: 3365 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-Type: comment X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/3365#issuecomment-2310076231 Content-Type: text/plain; charset=utf-8 By the way, it looks like the statement has `InputStream` for a `bytea` placeholder, so `.toString()` consumes the stream, and subsequent `.toString()` calls fail as they can no longer consume the stream. Previously, `toString()` returned `?` for `bytea`, so it was not an issue. It looks like the solution here would be to detect `.toString()` and store all the corresponding `InputStreams` buffer so we can replay them. ---- In any case, it looks like adding statements to `ConcurrentSkipListSet` does not sound good, and I believe it should be removed. > PLStatement below is a wrapper around PreparedStatement)- not knowing of the characteristics of the object being put into it of course If you do not care about the contents of `PreparedStatement` (`.toString()` does not compare the statements perfectly anyway), you could rather use `System.identityHashCode(preparedStatement)` for the statement comparison. It would yield a stable comparison, and it would not cause excessive resource consumption within `.toString()`. However, I still think disabling the statement cache would be the right thing as it would reduce CPU consumption, it would reduce memory consumption, and it would probably improve the performance at the same time.