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(at)gmail(dot)com>, wrote:
> 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!