@OliOlsz these are almost always harmless lock-contention “noise,” not data corruption. Pega uses a legacy pattern on PR_SYS_LOCKS (and a few scheduler/queue tables) where two threads try to INSERT the same lock row; the winner gets the lock, the loser hits a Postgres 23505 duplicate-key error that Pega catches and moves on. Under load, jobs like Alert/Queue processors and agents will spike these, so you’ll see keys like PYALERTJOB… in the messages. What this really means is: concurrency is working, but Postgres logs it at ERROR level, so it looks scary. Do three things: confirm the errors are almost entirely on PR_SYS_LOCKS/queue tables; ensure only intended nodes run each Job Scheduler/Queue Processor (no duplicate runners), and verify node IDs are unique and clocks are sane. If you truly see violations on business tables, check for sequence drift (nextval < max(id)) and repair with setval; otherwise ignore the lock duplicates or lower DB logging for 23505 via log filtering.