|
Home > Archive > PostgreSQL JDBC > November 2005 > rollback ignored until end of transaction block
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
rollback ignored until end of transaction block
|
|
| Kevin Grittner 2005-11-22, 8:24 pm |
| 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(Query
ExecutorImpl.java:1297)
at
org.postgresql.core.v3.QueryExecutorImpl. execute(QueryExecuto
rImpl.java:188)
at
org.postgresql.jdbc2. AbstractJdbc2Connect
ion. executeTransactionCo
mmand(AbstractJdbc2C
onnection.java:617)
at
org.postgresql.jdbc2. AbstractJdbc2Connect
ion. rollback(AbstractJdb
c2Connection.java:654)
<application code>
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
| Scott Marlowe 2005-11-22, 8:24 pm |
| 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(Query
ExecutorImpl.java:1297)
> at
> org.postgresql.core.v3.QueryExecutorImpl. execute(QueryExecuto
rImpl.java:188)
> at
> org.postgresql.jdbc2. AbstractJdbc2Connect
ion. executeTransactionCo
mmand(AbstractJdbc2C
onnection.java:617)
> at
> org.postgresql.jdbc2. AbstractJdbc2Connect
ion. rollback(AbstractJdb
c2Connection.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.
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
| |
| Oliver Jowett 2005-11-22, 8:24 pm |
| 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(Query
ExecutorImpl.java:1297)
> at
> org.postgresql.core.v3.QueryExecutorImpl. execute(QueryExecuto
rImpl.java:188)
> at
> org.postgresql.jdbc2. AbstractJdbc2Connect
ion. executeTransactionCo
mmand(AbstractJdbc2C
onnection.java:617)
> at
> org.postgresql.jdbc2. AbstractJdbc2Connect
ion. rollback(AbstractJdb
c2Connection.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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
| Kris Jurka 2005-11-22, 8:24 pm |
|
On Wed, 23 Nov 2005, Oliver Jowett wrote:
> Kevin Grittner wrote:
>
> 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/pgsq...11/msg00094.php
Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Kevin Grittner 2005-11-22, 8:24 pm |
| 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
Kevin Grittner wrote:[color=darkred
]
> 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(Query
ExecutorImpl. java:1297)
> at
>
org.postgresql.core.v3.QueryExecutorImpl. execute(QueryExecuto
rImpl. java:188)
> at
>
org.postgresql.jdbc2. AbstractJdbc2Connect
ion. executeTransactionCo
mmand(AbstractJdbc2C
onnection. java:617)
> at
>
org.postgresql.jdbc2. AbstractJdbc2Connect
ion. rollback(AbstractJdb
c2Connection.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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
| |
| Oliver Jowett 2005-11-22, 8:24 pm |
| Kris Jurka wrote:
>
>
> On Wed, 23 Nov 2005, Oliver Jowett wrote:
>
>
> This thread might be relevent. Checking might have been tightened up
> too much?
>
> http://archives.postgresql.org/pgsq...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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
| Kevin Grittner 2005-11-22, 8:24 pm |
| 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
[color=darkred]
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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
| Kris Jurka 2005-11-22, 8:24 pm |
|
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
processDeadParsedQue
ries or processDeadPortals doesn't like getting run in
a stalled transaction.
Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
| |
| Oliver Jowett 2005-11-22, 8:24 pm |
| Kris Jurka wrote:
>
>
> On Wed, 23 Nov 2005, Oliver Jowett wrote:
>
>
> Another idea that occurred to me that I don't have time to test is that
> processDeadParsedQue
ries 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. AbstractJdbc2Connect
ion$TransactionComma
ndHandler@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(ROLLBA
CK)
<=BE ReadyForQuery(I)
rollback was ok
-O
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
| |
| Kevin Grittner 2005-11-23, 8:24 pm |
| 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
Kevin Grittner wrote:[color=darkred
]
> 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(Query
ExecutorImpl. java:1297)
> at
>
org.postgresql.core.v3.QueryExecutorImpl. execute(QueryExecuto
rImpl. java:188)
> at
>
org.postgresql.jdbc2. AbstractJdbc2Connect
ion. executeTransactionCo
mmand(AbstractJdbc2C
onnection. java:617)
> at
>
org.postgresql.jdbc2. AbstractJdbc2Connect
ion. rollback(AbstractJdb
c2Connection.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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
| |
| Oliver Jowett 2005-11-23, 8:24 pm |
| 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
|
|
|
|
|