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: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Christian Kruse <christian(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 17:00:07
Message-ID: 12774.1390410007@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> This ngettext() call is repeated four times in the new code, which is a
> bit annoying because it's not trivial. I think you could assign the
> ngettext() to a char * at the bottom of the loop, and then in the
> ereport() calls use it:

Would that not break the compiler's ability to verify the format codes
in the string? Not to mention make it harder for people to compare
format to arguments, too?

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2014-01-22 17:05:48 Re: WAL replay should fdatasync() segments?
Previous Message Andres Freund 2014-01-22 16:51:33 Re: dynamic shared memory and locks