I know this was a long time ago, do you still have interest in pursuing this patch Alexey? Having this capability would be a big help when debugging locking issues after the fact. Re. The fact that the last query isn’t necessarily the one holding the lock - yes that’s annoying but even so, knowing which was the last query executed by the blocking process would help as it allows one to narrow down what job/process is causing the locking. On 3 Oct 2024 at 11:33 +0200, Alexey Orlov <[email protected]>, wrote: > On Thu, Oct 3, 2024 at 3:58 AM David Rowley <[email protected]> wrote: > > > > On Tue, 1 Oct 2024 at 21:04, Alexey Orlov <[email protected]> wrote: > > > session 1: > > > CREATE TABLE foo (val integer); > > > INSERT INTO foo (val) VALUES (1); > > > BEGIN; > > > UPDATE foo SET val = 3; > > > > > > session 2: > > > BEGIN; > > > UPDATE TABLE foo SET val = 2; > > > > > > LOG: process 3133043 still waiting for ShareLock on transaction 758 > > > after 1000.239 ms > > > DETAIL: Process holding the lock: 3132855. Wait queue: 3133043. > > > Process 3132855: update foo SET val = 3; > > > CONTEXT: while updating tuple (0,7) in relation "foo" > > > STATEMENT: update foo SET val = 2; > > > > > What do you think? > > > > Can you explain why the last query executed by the blocking process is > > relevant output to show? Are you just hoping that the last statement > > to execute is the one that obtained the lock? Wouldn't it be confusing > > if the last query to execute wasn't the query which obtained the lock? > > > > David > Thanks for the review! I completely agree with you, relying on chance is > wrong. > What if I do a small check? I’ll check whether the command string has > changed during the DeadLockTimeout. > And if so we will see in the log: > > Process holding the lock: 1057195. Wait queue: 1057550. > Process 1057195: <command string has been changed> > > I have shared updated patch[3] > > -- > Regards, > Alexey Orlov!
