For the benefit of anyone with similar problems who finds this thread,
I'm posting resolution info. The problem was that Statement.cancel
was being invoked at the end of an empty ResultSet, and that a race
condition on the server can cause a subsequent commit to return this
error -- if the commit occurs very soon after the Statement.cancel.

See the admin list for more info.

-Kevin


>>> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> 08/18/05 5:40 PM >>>
Thanks much for the clarification. The statement_timeout setting is commented out, with a note that it defaults to zero and that this means it is disabled.

I'm moving this discussion to the admin group. The failure occurs with the PostgreSQL server running on Windows Advanced Server 2003, while the same software and configuration works fine with the server on Windows 2000. If nobody can suggest a configuration change to Windows to fix this I guess I'll report it as a bug on Windows 2003 and try to convince management here to use a different platform. (I've been pushing Linux, but the DBA manager doesn't want to change both OS and DBMS at the same time.)

-Kevin


>>> Oliver Jowett <oliver@opencloud.com> 08/18/05 4:56 PM >>>
Kevin Grittner wrote:

> I searched to ensure that nothing was invoking the Statement.setQueryTimeout method.

setQueryTimeout() is a no-op anyway in current drivers. I was talking
about the server's statement_timeout setting (set in postgresql.conf or
via SET or on a per-user/db basis).

> Hypothetically, would such a bug most likely be strictly server-side (in which case this is the wrong forum to pursue it)

Yes.


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq