Re: Unable to commit: transaction marked for rollback - Mailing list pgsql-jdbc

From David Kerr
Subject Re: Unable to commit: transaction marked for rollback
Date
Msg-id 4C2CFDE1.1020308@mr-paradox.net
Whole thread Raw
In response to Re: Unable to commit: transaction marked for rollback  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Unable to commit: transaction marked for rollback
List pgsql-jdbc
On 7/1/2010 12:20 PM, Kevin Grittner wrote:
> David Kerr<dmk@mr-paradox.net>  wrote:
>
>> Would postgres normally log the error in the TX?
>
> A previous statement should have generated the original exception,
> if that's what you mean.
ok.

>> (it's not, which is why i'm asking)
>
> Where are you checking?  If you're talking about exceptions you're
> fielding, it wouldn't be the first time I've seen sloppy exception
> handling hide the first exception (the one that actually matters)
> and throw a secondary exception.  One common mistake is to catch the
> first exception and try to do some cleanup, but allow an exception
> to be thrown from the cleanup code -- completely hiding the first
> exception.
I'm checking the Postgres logs. (I'm not Java savvy, but i'll pass the
info along to my developers)

> > There are, of course, variations on this, but you get the gist of
> it.
>
> Have you checked the PostgreSQL log file for clues?  If you're not
> seeing what you need, you could tweak the logging to show more.

We're trying that, it's (of course) intermittent and happens after like
5 hours. so huge logfiles, etc as usual. With log_statements=none turned
on PG logs database errors. so it seems like whatever's happening isn't
being considered an "error". more of a natural database transaction
(like a lock) or something. does that sound about right?

Thanks

Dave

pgsql-jdbc by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Unable to commit: transaction marked for rollback
Next
From: "Kevin Grittner"
Date:
Subject: Re: Unable to commit: transaction marked for rollback