Re: Augmenting the deadlock message with application_name

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.

In response to

Responses

Browse pgsql-hackers by date

  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.