Re: Patch: Show queries of processes holding a lock

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