Hi, The log you expose doesn’t mean a dead lock! It comes from setting deadlock_timeout parameter. Its value is 1 second by default. When a session waits for a lock more than this threshold then a test to see if we are in a deadlock condition is triggered. It is simply that we are waiting to obtain a lock for longer that the value of deadlock_timeout. Any way it could be interpreted as a performance problem when we are frequently waiting more than 1 sec for a lock… Regards Michel SALAIS De : Edwin UY <edwin.uy@xxxxxxxxx> Thanks Tom, OK, I've decided to 'painfully' look at the PostgreSQL RDS logs and it is showing something like below. There seems to be a locking/deadlock issue of some sort somewhere. I have checked the other days' log prior to the patching and these appear to be a 'normal' occurrence for this database and it wasn't affecting the application nonetheless. After the patching, it starts affecting the application. Not sure what else I can check on the Aurora PostgreSQL RDS end. I may request them to restart the app server. [25751]:LOG: process 25751 still waiting for ShareLock on transaction 114953443 after 1000.054 ms [25751]:DETAIL: Process holding the lock: 22297. Wait queue: 25751. [25751]:CONTEXT: while locking tuple (1,17) in relation "[table_name]" [25751]:STATEMENT: [SQL_STATEMENT] for update On Mon, Nov 11, 2024 at 5:45 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
|
