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
zeroand 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
AdvancedServer 2003, while the same software and configuration works fine with the server on Windows 2000. If nobody
cansuggest a configuration change to Windows to fix this I guess I'll report it as a bug on Windows 2003 and try to
convincemanagement here to use a different platform. (I've been pushing Linux, but the DBA manager doesn't want to
changeboth 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.