search cancel

Time Slicing deadlocks on multiple tables on PostgreSQL (GCP)


Article ID: 221066


Updated On:


Clarity PPM SaaS Clarity PPM On Premise


Seeing Time Slicing failing with deadlocks repeatedly. The BG Log file shows errors for different tables such as: prj_baseline_details, prteam, prassignment, prj_blb_slices_d_alc, odf_ssl_cst_dtl_aunits, prj_tentative_assignments. 

Steps to Reproduce:

  1. Set up an live environment with concurrent updates in MUX on Clarity and SQL Curves enabled
  2. Schedule Time Slicing job to run as default, every 1 min

Expected Results: The job to run as expected. 

Actual Results: The Time Slicing job repeatedly fails with deadlocks (could be up to 10-20 times per day). 

Here is an example of one deadlock on one of the tables: 

ERROR 2021-07-27 11:16:50,543 [Dispatch Time Slicing : [email protected](tenant=clarity)] niku.blobcrack 
(clarity:admin:22542126__382C3001-AE60-4E08-8A3D-A80E179D253E:Time Slicing) Exception during blobcrack process

SQL error code: 0
Error message: ERROR: deadlock detected
  Detail: Process 24368 waits for ShareLock on transaction 4050256554; blocked by process 20060.
Process 20060 waits for ShareLock on transaction 4050256592; blocked by process 24368.
  Hint: See server log for query details.
  Where: while locking tuple (22095,8) in relation "prj_baseline_details"
              SET SLICE_STATUS = 1
              WHERE BASELINE_ID IN
                 SELECT B.ID
                 FROM PRJ_BASELINES B
                 WHERE B.SLICE_STATUS = 2


Release : 15.9.2, 15.9.3


This is DE62122, fixed in 16.0.0

Workaround: None, ignore the deadlock and the record will usually be picked up on the next run. 

Additional Information

Reference the following articles for the 'fin_cost_plan_details' deadlocks which are NOT INCLUDED in the resolution of this defect. 

See also: