Re: Patch: Show queries of processes holding a lock

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Alexey Orlov <aporlov(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Patch: Show queries of processes holding a lock
Date: 2024-10-03 00:58:12
Message-ID: CAApHDvpd9FwxyfuA4hZDWUM68O2nj1DrKr9iS2t_adTCnkExhg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2024-10-03 01:20:17 Re: Enhance create subscription reference manual
Previous Message Peter Smith 2024-10-03 00:53:26 Re: Pgoutput not capturing the generated columns