Should I be concerned with seeing APM database deadlock errors and exceptions in the Tess logs and the postgresql.log?

Document ID:  TEC596464
Last Modified Date:  06/12/2017
{{active ? 'Hide' : 'Show'}} Technical Document Details


  • CA Application Performance Management


  • CA Application Performance Management:Release:10.0
  • CA Application Performance Management:Release:10.1
  • CA Application Performance Management:Release:10.2
  • CA Application Performance Management:Release:10.3
  • CA Application Performance Management:Release:10.5
  • CA Application Performance Management:Release:10.5.1
  • CA Application Performance Management:Release:10.5.2



This is another knowledge document on the operations of the APM database.


Seeing the following database log entries. Should I be concerned?

Tess Log error:

tess.log (retry due to deadlock exception): 
2009-09-22 08:28:32,450 [DefectThreadPool-25] INFO [] - <User Info Retrying # 1 for defectDefId = 600000000000000133 with session id = 0000XcYZXwPgl_HEY6wULF6Sifv:13g6ctrr7> 
...................db deadlock Exception...............
2009-09-22 08:28:33,508 [DefectThreadPool-25] INFO [] - <No user info available. Retrying the processing of BizEvent: 600000000000000065 with total of defects: 1> 
2009-09-22 08:28:33,834 [DefectThreadPool-12] INFO [] - <User Info Retrying # 2 for defectDefId = 600000000000000133 with session id = 0000XcYZXwPgl_HEY6wULF6Sifv:13g6ctrr7> 
2009-09-22 08:28:33,932 [DefectThreadPool-12] INFO [] - <No user info available. Retrying the processing of BizEvent: 600000000000000065 with total of defects: 1> 
2009-09-22 08:28:34,066 [DefectThreadPool-3] INFO [] - <No user found for login '' and session '0000XcYZXwPgl_HEY6wULF6Sifv:13g6ctrr7'>


Deadlock exception while update...... ( reported by postgresql in postgresql.log): 
 [8028-cemdb-admin-2009-09-22 08:28:33.464 PDT]ERROR: deadlock detected 
[8028-cemdb-admin-2009-09-22 08:28:33.464 PDT]DETAIL: Process 8028 waits for ShareLock on transaction 155924; blocked by process 8262. 
Process 8262 waits for ExclusiveLock on tuple (5,46) of relation 16420 of database 16385; blocked by process 8028. 
[8028-cemdb-admin-2009-09-22 08:28:33.464 PDT]STATEMENT: update ts_biz_events set version_info=$1, ts_transet_id=$2, ts_transet_incarnation_id=$3, ts_defect_def_id=$4, ts_name=$5, ts_business_impact=$6, ts_start_date=$7, ts_trigger_date=$8, ts_last_modified=$9, ts_close_date=$10, ts_number_of_defects=$11, ts_number_of_groups=$12, ts_number_of_users=$13, ts_status=$14, ts_impact_threshold=$15, ts_cause=$16, ts_resolution=$17, ts_closed_by=$18, ts_ticket_number=$19, ts_assignee=$20, ts_evidence_on_open=$21, ts_evidence=$22, ts_evidence2=$23, ts_evidence3=$24, ts_soft_delete=$25 where ts_id=$26 and version_info=$27 

All supported APM and Postgres releases

Tess shows this message at the INFO level because it is trying to recover from it. On the PostgreSQL side it appears under the ERROR category as it is a severe exception.

Typically, we can ignore these database deadlock exceptions. Usually, the database implementation provides a recovery mechanism.

PostgreSQL (the APM database) recovers from the deadlocks using the deadlock detector background thread.

As per the PostgreSQL manual (See "13.3.4. Deadlocks" section in the below link which is always pointing to the latest Postgres release.), it suggests that applications should have a retry mechanism for deadlock exceptions

TESS already has a retry mechanism and it is recovering from such situations. So, these exceptions can be ignored.

Please help us improve!

Will this information enable you to resolve your issue?

Please tell us what we can do better.

{{feedbackText.length ? feedbackText.length : '0'}}/255


Not what you were looking for?

Search Again >

Product Information

Support by Product >


Join a Community >