Обсуждение: rollback ignored until end of transaction block
Is there any context where this would make sense?:
org.postgresql.util.PSQLException: ERROR: current transaction is
aborted, commands ignored until end of transaction block
at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1512)
at
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1297)
at
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:188)
at
org.postgresql.jdbc2.AbstractJdbc2Connection.executeTransactionCommand(AbstractJdbc2Connection.java:617)
at
org.postgresql.jdbc2.AbstractJdbc2Connection.rollback(AbstractJdbc2Connection.java:654)
<application code>
On Tue, 2005-11-22 at 14:51, Kevin Grittner wrote: > Is there any context where this would make sense?: > > org.postgresql.util.PSQLException: ERROR: current transaction is > aborted, commands ignored until end of transaction block > at > org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1512) > at > org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1297) > at > org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:188) > at > org.postgresql.jdbc2.AbstractJdbc2Connection.executeTransactionCommand(AbstractJdbc2Connection.java:617) > at > org.postgresql.jdbc2.AbstractJdbc2Connection.rollback(AbstractJdbc2Connection.java:654) > <application code> There was an error earlier in your transaction. This error is simply telling you that nothing you do until you close this transaction will be accepted and acted upon. You need to get the earlier error that caused the transaction to abort.
Kevin Grittner wrote: > Is there any context where this would make sense?: > > org.postgresql.util.PSQLException: ERROR: current transaction is > aborted, commands ignored until end of transaction block > at > org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1512) > at > org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1297) > at > org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:188) > at > org.postgresql.jdbc2.AbstractJdbc2Connection.executeTransactionCommand(AbstractJdbc2Connection.java:617) > at > org.postgresql.jdbc2.AbstractJdbc2Connection.rollback(AbstractJdbc2Connection.java:654) Huh, that *is* weird. rollback() should do nothing but execute ROLLBACK, which shouldn't trigger that error.. How did you get it into that state? Can you run with loglevel=2 and see what the trace says? What driver version? -O
On Wed, 23 Nov 2005, Oliver Jowett wrote: > Kevin Grittner wrote: >> Is there any context where this would make sense?: >> >> org.postgresql.util.PSQLException: ERROR: current transaction is >> aborted, commands ignored until end of transaction block > > Huh, that *is* weird. rollback() should do nothing but execute ROLLBACK, > which shouldn't trigger that error.. How did you get it into that state? Can > you run with loglevel=2 and see what the trace says? What driver version? > This thread might be relevent. Checking might have been tightened up too much? http://archives.postgresql.org/pgsql-bugs/2005-11/msg00094.php Kris Jurka
The driver is the download of this file: postgresql-8.1-404.jdbc3.jar (We didn't do our own build on this.) The logging from our app isn't giving anything beyond this exception and stack trace. We're running hundreds of thousands of transactions per day in, with a pattern of: (1) Try a number of separate insert/update/delete operations in a single database transaction. Deletes and updates are done through updateable result sets. Inserts are done through prepared statements. (2) If an exception is thrown, cancel the statement, close the result set (if open), close the statement, and retry in "cautious mode". While in cautious mode, updates of nonexistant rows become inserts, inserts of duplicate rows become updates, oversized strings are truncated, etc., and a commit is done of each insert/update/delete. During a window of time I'm looking at, we processed about 50,000 of the high level transactions in about 90 minutes. We had three of these rollback problems. Nothing showed in the postmaster log at the time of these exceptions. If I were to run with loglevel=2 with this load for an hour or two, how big do you think the log file would get? -Kevin >>> Oliver Jowett <oliver@opencloud.com> >>> Kevin Grittner wrote: > Is there any context where this would make sense?: > > org.postgresql.util.PSQLException: ERROR: current transaction is > aborted, commands ignored until end of transaction block > at > org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1512) > at > org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1297) > at > org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:188) > at > org.postgresql.jdbc2.AbstractJdbc2Connection.executeTransactionCommand(AbstractJdbc2Connection.java:617) > at > org.postgresql.jdbc2.AbstractJdbc2Connection.rollback(AbstractJdbc2Connection.java:654) Huh, that *is* weird. rollback() should do nothing but execute ROLLBACK, which shouldn't trigger that error.. How did you get it into that state? Can you run with loglevel=2 and see what the trace says? What driver version? -O
Kris Jurka wrote: > > > On Wed, 23 Nov 2005, Oliver Jowett wrote: > >> Kevin Grittner wrote: >> >>> Is there any context where this would make sense?: >>> >>> org.postgresql.util.PSQLException: ERROR: current transaction is >>> aborted, commands ignored until end of transaction block >> >> >> Huh, that *is* weird. rollback() should do nothing but execute >> ROLLBACK, which shouldn't trigger that error.. How did you get it into >> that state? Can you run with loglevel=2 and see what the trace says? >> What driver version? >> > > This thread might be relevent. Checking might have been tightened up > too much? > > http://archives.postgresql.org/pgsql-bugs/2005-11/msg00094.php I just tried against a server built from HEAD and couldn't reproduce the problem any of the obvious ways.. Think we will need a testcase here. -O
That may be hard to do. I'll modify the code to log as much as possible when the rollback fails -- in hopes of finding a clue. Thanks for taking a look. -Kevin >>> Oliver Jowett <oliver@opencloud.com> >>> I just tried against a server built from HEAD and couldn't reproduce the problem any of the obvious ways.. Think we will need a testcase here. -O
On Wed, 23 Nov 2005, Oliver Jowett wrote: > I just tried against a server built from HEAD and couldn't reproduce the > problem any of the obvious ways.. Think we will need a testcase here. > Another idea that occurred to me that I don't have time to test is that processDeadParsedQueries or processDeadPortals doesn't like getting run in a stalled transaction. Kris Jurka
Kris Jurka wrote: > > > On Wed, 23 Nov 2005, Oliver Jowett wrote: > >> I just tried against a server built from HEAD and couldn't reproduce >> the problem any of the obvious ways.. Think we will need a testcase here. >> > > Another idea that occurred to me that I don't have time to test is that > processDeadParsedQueries or processDeadPortals doesn't like getting run > in a stalled transaction. No errors against CVS HEAD with the CloseStatement/ClosePortal messages being sent after an error, just before the ROLLBACK: [...] <=BE ReadyForQuery(E) caught expected exception closing query: select * from pg_proc simple execute, handler=org.postgresql.jdbc2.AbstractJdbc2Connection$TransactionCommandHandler@6443226, maxRows=0, fetchSize=0, flags=22 FE=> CloseStatement(S_11) FE=> ClosePortal(C_12) FE=> Bind(stmt=S_4,portal=null) FE=> Execute(portal=null,limit=1) FE=> Sync <=BE CloseComplete <=BE CloseComplete <=BE BindComplete [null] <=BE CommandStatus(ROLLBACK) <=BE ReadyForQuery(I) rollback was ok -O
I haven't seen any of these today. Ran part of the day with loglevel=2 and part without. I'll keep trying. We have fixed a couple underlying exceptions which might have set up the conditions for this. Is it worth intentionally regressing those in my application code to try to track this down if it doesn't otherwise manifest? It is disconcerting to be told that a rollback won't be accepted until the end of the transaction block. :-( -Kevin >>> Oliver Jowett <oliver@opencloud.com> >>> Kevin Grittner wrote: > Is there any context where this would make sense?: > > org.postgresql.util.PSQLException: ERROR: current transaction is > aborted, commands ignored until end of transaction block > at > org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1512) > at > org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1297) > at > org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:188) > at > org.postgresql.jdbc2.AbstractJdbc2Connection.executeTransactionCommand(AbstractJdbc2Connection.java:617) > at > org.postgresql.jdbc2.AbstractJdbc2Connection.rollback(AbstractJdbc2Connection.java:654) Huh, that *is* weird. rollback() should do nothing but execute ROLLBACK, which shouldn't trigger that error.. How did you get it into that state? Can you run with loglevel=2 and see what the trace says? What driver version? -O
Kevin Grittner wrote: > I haven't seen any of these today. Ran part of the day with loglevel=2 > and part without. I'll keep trying. > > We have fixed a couple underlying exceptions which might have set > up the conditions for this. Is it worth intentionally regressing those > in > my application code to try to track this down if it doesn't otherwise > manifest? It is disconcerting to be told that a rollback won't be > accepted until the end of the transaction block. :-( Well, it certainly shouldn't happen, but I can't reproduce it here so it's pretty much in your hands.. If it does happen again then hopefully loglevel=2 output will be sufficient to work out what's going on. -O