Re: Augmenting the deadlock message with application_name

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Karoline Pauls <code(at)karolinepauls(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, "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 21:01:27
Message-ID: 1636764.1715374887@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Karoline Pauls <code(at)karolinepauls(dot)com> writes:
> On Friday, 10 May 2024 at 20:17, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> log_line_prefix supports application name --- why would you not use
>> that?

> log_line_prefix is effective in the server log. This change is mostly about improving the message sent back to the client. While the server log is also changed to reflect the client message, it doesn't need to be.

It's normally necessary to look at the server log anyway if you want
to figure out what caused the deadlock, since the client message
intentionally doesn't provide query texts. I think this proposal
doesn't move the goalposts noticeably: it seems likely to me that
in many installations the sessions would mostly all have the same
application_name, or at best not-too-informative names like "psql"
versus "PostgreSQL JDBC Driver". (If we thought these names *were*
really informative about what other sessions are doing, we'd probably
have to hide them from unprivileged users in pg_stat_activity, and
then there'd also be a security concern here.)

On the whole I'd reject this proposal as causing churn in
application-visible behavior for very little gain.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2024-05-10 21:09:57 Re: Augmenting the deadlock message with application_name
Previous Message Nathan Bossart 2024-05-10 21:00:55 Re: pg_sequence_last_value() for unlogged sequences on standbys