Thread: PGobject returned from ResultSet.getObject
Attached is a code snippet and the problems from running about 390,000 queries overnight. This has been happening for us, at low volume, since we started using PostgreSQL -- initially with the jars that were release in conjunction with 8.0. It has happened with the jars released in conjunction with 8.1. This latest listing is from a JDBC driver built off the trunk as of Jan. 13th. Athena and Plato are two identical PostgreSQL 8.1.2 databases, which are the targets of identical updates. In the process generating these problems, the same SELECT queries were run against both databases at the same time. While they both had some of these problems (on the order of 0.001% of the queries run), they did not occur on the SAME queries. All columns are defined with either a normal ANSI data type or a DOMAIN which maps to a normal ANSI data type. This smells like a race condition of some sort, but I'm not sure how. Any ideas on where to look or what we could programatically check for when we see one of these? I'm casting about for ideas which would avoid turning on debug logging in the JDBC driver, although I suspect that may be what we wind up having to do. -Kevin
Attachment
Kevin, Can you give us more information. Is this using a pool, threads? Basically the type information comes back in the protocol, so it would appear that is getting scribbled on. It would be interesting to see if the rest of the fields are still good after the bad one? Dave On 8-Feb-06, at 4:48 PM, Kevin Grittner wrote: > Attached is a code snippet and the problems from running about 390,000 > queries overnight. This has been happening for us, at low volume, > since > we started using PostgreSQL -- initially with the jars that were > release > in conjunction with 8.0. It has happened with the jars released in > conjunction with 8.1. This latest listing is from a JDBC driver built > off the trunk as of Jan. 13th. > > Athena and Plato are two identical PostgreSQL 8.1.2 databases, which > are the targets of identical updates. In the process generating these > problems, the same SELECT queries were run against both databases > at the > same time. While they both had some of these problems (on the > order of > 0.001% of the queries run), they did not occur on the SAME > queries. All > columns are defined with either a normal ANSI data type or a DOMAIN > which maps to a normal ANSI data type. > > This smells like a race condition of some sort, but I'm not sure how. > Any ideas on where to look or what we could programatically check for > when we see one of these? I'm casting about for ideas which would > avoid > turning on debug logging in the JDBC driver, although I suspect > that may > be what we wind up having to do. > > -Kevin > > > <PGobject-problems.txt> > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings
>>> On Wed, Feb 8, 2006 at 7:15 pm, in message <A74BA11E-BC48-43E4-B5FD-7835C26217D0@fastcrypt.com>, Dave Cramer <pg@fastcrypt.com> wrote: > > Can you give us more information. Is this using a pool, threads? We have a set of worker threads dealing with requests from a queue, with one JDBC connection per thread. The only time a separate thread invokes any methods on the JDBC objects is the occasional Statement.cancel(). > It would be interesting to see if the rest of the fields are still > good after the bad one? I assume that this is the same issue addressed by the patch posted this morning by Till Toenges. ( http://archives.postgresql.org/pgsql-jdbc/2006-02/msg00066.php ) Is there still any need to try to get this information about subsequent columns? -Kevin