From: | Alexey Orlov <aporlov(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Patch: Show queries of processes holding a lock |
Date: | 2024-09-30 20:15:38 |
Message-ID: | CALjmG4+8rGvebbHBHHARuUMS5SAEepFnLZyCCE8bpt7XZbet8g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi, there!
I created patch improving the log messages generated by
log_lock_waits.
Sample output (log_lock_waits=on required):
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;
Output w/o patch:
LOG: process 3133043 still waiting for ShareLock on transaction 758
after 1000.239 ms
DETAIL: Process holding the lock: 3132855. Wait queue: 3133043.
CONTEXT: while updating tuple (0,7) in relation "foo"
STATEMENT: update foo SET val = 2;
Output with path
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;
As you can see information about query that holds the lock goes into log.
If this approach proves unacceptable, we can make the log_lock_waits
parameter as an enum
and display the query if the log_lock_waits=verbose (for example).
What do you think?
Regards,
--
Orlov Alexey
Attachment | Content-Type | Size |
---|---|---|
v-1-0001-Show-queries-in-log_lock_wait_log.patch | text/x-patch | 2.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2024-09-30 21:16:25 | Re: index prefetching |
Previous Message | Robert Haas | 2024-09-30 20:11:58 | Re: pg_verifybackup: TAR format backup verification |