When an OOPS occurs because of a psycopgda Retry exception (e.g. OOPS-45A331), the traceback doesn't include any information about what the query that failed was.
Jamesh suggested in bug 39441:
"To help debug these problems, it would be useful to see the details of the wrapped exception/traceback, and include them in the OOPS report.
This could either be done specific to Retry exceptions, or we could try and detect wrapped exceptions with something like:
if len(value.args) == 3 and issubclass(value.args[0], Exception) and isinstance(value.args[2], traceback):
...
The additional traceback could just be appended after the first traceback in the OOPS report."
SteveA suggested in bug 92185 more information that we should capture in cases like this:
"OOPS reports should take into account whether the request has been retried by showing how many retries occurred, and preferably showing independently the SQL and non-SQL time for each retry. This will allow us to see whether retried requests are using a lot of database resources, particularly with transactions involving writes to the database, it will help us debug cases where state that should be reset on a Retry is not reset, and will give us insight into whether some OOPS reports that have a lot of non-sql time are requests that were retried. That is, if we're resetting the SQL statement log on a Retry, but not resetting the non-sql-time counter."
Steve's asked me to work on this.