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 <aporlov@gmail.com>, wrote:
On Thu, Oct 3, 2024 at 3:58 AM David Rowley <dgrowleyml@gmail.com> wrote:
On Tue, 1 Oct 2024 at 21:04, Alexey Orlov <aporlov@gmail.com> 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!
