From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Karoline Pauls <code(at)karolinepauls(dot)com> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Augmenting the deadlock message with application_name |
Date: | 2024-05-10 19:17:18 |
Message-ID: | Zj5yvhhYmHWgnnDf@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 9, 2024 at 11:44:03PM +0000, Karoline Pauls wrote:
> As we know, the deadlock error message isn't the most friendly one. All the
> client gets back is process PIDs, transaction IDs, and lock types. You have to
> check the server log to retrieve lock details. This is tedious.
>
> In one of my apps I even added a deadlock exception handler on the app side to
> query pg_stat_activity for processes involved in the deadlock and include their
> application names and queries in the exception message. It is a little racy but
> works well enough.
>
> Ideally I'd like to see that data coming from Postgres upon detecting the
> deadlock. That's why I made this small change.
>
> The change makes the deadlock error look as follows - the new element is the
> application name or "<insufficient privilege>" in its place if the activity
> user doesn't match the current user (and the current use isn't a superuser):
>
> postgres=*> SELECT * FROM q WHERE id = 2 FOR UPDATE;
> ERROR: deadlock detected
> DETAIL: Process 194520 (application_name: <insufficient privilege>) waits for
> ShareLock on transaction 776; blocked by process 194521.
> Process 194521 (application_name: woof) waits for ShareLock on transaction 775;
> blocked by process 194520.
> HINT: See server log for query details.
> CONTEXT: while locking tuple (0,2) in relation "q"
log_line_prefix supports application name --- why would you not use
that?
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2024-05-10 19:27:11 | Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index. |
Previous Message | Alexander Korotkov | 2024-05-10 19:05:01 | Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index. |