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