Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christian Kruse <christian(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire
Date: 2014-01-22 19:45:00
Message-ID: 17004.1390419900@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Christian Kruse <christian(at)2ndquadrant(dot)com> writes:
>> However, the real problem here is that you shouldn't be calling ngettext
>> manually in an ereport context in the first place. There is
>> infrastructure in place for that, and this isn't using it.

> Fixed in attached patch. I changed it from calling
> errorcontext(ngettext()) to calling errdetail_plural().

Well, is it context or detail? Those fields have reasonably well defined
meanings IMO.

If we need errcontext_plural, let's add it, not adopt inferior solutions
just because that isn't there for lack of previous need.

But having said that, I think this is indeed detail not context.
(I kinda wonder whether some of the stuff that's now in the primary
message shouldn't be pushed to errdetail as well. It looks like some
previous patches in this area have been lazy.)

While I'm griping, this message isn't even trying to follow the project's
message style guidelines. Detail or context messages are supposed to be
complete sentence(s), with capitalization and punctuation to match.

Lastly, is this information that we want to be shipping to clients?
Perhaps from a security standpoint that's not such a wise idea, and
errdetail_log() is what should be used.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2014-01-22 20:28:43 Re: proposal: hide application_name from other users
Previous Message Jim Nasby 2014-01-22 19:35:36 Re: plpgsql.consistent_into