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

2014-03-12 Thread Christian Kruse
Hi, On 13/03/14 03:27, Fujii Masao wrote: > Committed! Thank you very much! Best regards, -- Christian Kruse http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services pgpkDoVMmXIL4.pgp Description: PGP signature

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

2014-03-12 Thread Fujii Masao
On Tue, Feb 25, 2014 at 1:03 PM, Rajeev rastogi wrote: > On 04 February 2014 14:38, Myself wrote: > >> >> On 4th February 2014, Christian kruse Wrote: >> > On 04/02/14 12:38, Fujii Masao wrote: >> > > ISTM that the phrase "Request queue" is not used much around the >> lock. >> > > Using the phrase

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

2014-02-24 Thread Rajeev rastogi
On 04 February 2014 14:38, Myself wrote: > > On 4th February 2014, Christian kruse Wrote: > > On 04/02/14 12:38, Fujii Masao wrote: > > > ISTM that the phrase "Request queue" is not used much around the > lock. > > > Using the phrase "wait queue" or Simon's suggestion sound better to > > at least

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

2014-02-04 Thread Rajeev rastogi
On 4th February 2014, Christian kruse Wrote: > On 04/02/14 12:38, Fujii Masao wrote: > > ISTM that the phrase "Request queue" is not used much around the lock. > > Using the phrase "wait queue" or Simon's suggestion sound better to > at least me. > > Thought? > > Sounds reasonable to me. Attached

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

2014-02-04 Thread Christian Kruse
Hi, On 04/02/14 12:38, Fujii Masao wrote: > ISTM that the phrase "Request queue" is not used much around the lock. > Using the phrase "wait queue" or Simon's suggestion sound better to at least > me. > Thought? Sounds reasonable to me. Attached patch changes messages to the following: Process h

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

2014-02-03 Thread Fujii Masao
On Mon, Feb 3, 2014 at 8:53 PM, Christian Kruse wrote: > Hi Simon, > > On 03/02/14 10:43, Simon Riggs wrote: >> > Singular: >> > "The following process is holding the lock: A. The request queue >> > consists of: B." >> > >> > Plural: >> > "Following processes are holding the lock: A, B. The reques

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

2014-02-03 Thread Christian Kruse
Hi Simon, On 03/02/14 10:43, Simon Riggs wrote: > > Singular: > > "The following process is holding the lock: A. The request queue > > consists of: B." > > > > Plural: > > "Following processes are holding the lock: A, B. The request queue > > consists of: C." > > Seems too complex. How about this

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

2014-02-03 Thread Simon Riggs
On 3 February 2014 10:06, Christian Kruse wrote: > Hi, > > On 03/02/14 17:59, Fujii Masao wrote: >> Since you added errdetail_log_plural(), ISTM that you need to update >> sources.sgml. > > [x] Fixed. > >> >> While I'm griping, this message isn't even trying to follow the project's >> >> message s

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

2014-02-03 Thread Christian Kruse
Hi, On 03/02/14 17:59, Fujii Masao wrote: > Since you added errdetail_log_plural(), ISTM that you need to update > sources.sgml. [x] Fixed. > >> 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

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

2014-02-03 Thread Fujii Masao
On Sat, Feb 1, 2014 at 7:41 PM, Christian Kruse wrote: > Hi, > > On 01/02/14 02:45, Fujii Masao wrote: > >> LOG: process 33662 still waiting for ShareLock on transaction >> 1011 after 1000.184 ms >> DETAIL: Process holding the lock: 33660. Request queue: 33662. >> [... snip ...] >> L

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

2014-02-01 Thread Christian Kruse
Hi, On 01/02/14 02:45, Fujii Masao wrote: > LOG: process 33662 still waiting for ShareLock on transaction > 1011 after 1000.184 ms > DETAIL: Process holding the lock: 33660. Request queue: 33662. > [… snip …] > LOG: process 33665 still waiting for ExclusiveLock on tuple (0,4) > of

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

2014-01-31 Thread Fujii Masao
On Tue, Jan 28, 2014 at 6:39 PM, Rajeev rastogi wrote: > On 28/01/14, Christian Kruse wrote: >> > I have checked the revised patch. It looks fine to me except one >> minor code formatting issue. >> > In elog.c, two tabs are missing in the definition of function >> "errdetail_log_plural". >> > Plea

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

2014-01-28 Thread Rajeev rastogi
On 28/01/14, Christian Kruse wrote: > > I have checked the revised patch. It looks fine to me except one > minor code formatting issue. > > In elog.c, two tabs are missing in the definition of function > "errdetail_log_plural". > > Please run pgindent tool to check the same. > > I did, but this re

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

2014-01-28 Thread Christian Kruse
Hi, On 27/01/14 11:44, Rajeev rastogi wrote: > I have checked the revised patch. It looks fine to me except one minor code > formatting issue. > In elog.c, two tabs are missing in the definition of function > "errdetail_log_plural". > Please run pgindent tool to check the same. I did, but this

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

2014-01-27 Thread Rajeev rastogi
On 23/01/14, Christian Kruse wrote: > > Well, is it context or detail? Those fields have reasonably well > > defined meanings IMO. > > I find the distinction somewhat blurry and think both would be > appropriate. But since I wasn't sure I changed to detail. > > > If we need errcontext_plural, le

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

2014-01-23 Thread Christian Kruse
Hi, > I think you have attached wrong patch. Hurm. You are right, attached v3, not v4. Sorry. Best regards, -- Christian Kruse http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/stora

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

2014-01-23 Thread Rajeev rastogi
On 23/01/14 14:45, Christian Kruse wrote: > > Well, is it context or detail? Those fields have reasonably well > > defined meanings IMO. > > I find the distinction somewhat blurry and think both would be > appropriate. But since I wasn't sure I changed to detail. > > > If we need errcontext_plur

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

2014-01-22 Thread Christian Kruse
Hi, On 22/01/14 14:45, Tom Lane wrote: > Well, is it context or detail? Those fields have reasonably well defined > meanings IMO. I find the distinction somewhat blurry and think both would be appropriate. But since I wasn't sure I changed to detail. > If we need errcontext_plural, let's add it

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

2014-01-22 Thread Tom Lane
Christian Kruse 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(nge

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

2014-01-22 Thread Christian Kruse
Hi, attached you will find a new version of the patch containing more comments. On 22/01/14 12:00, Tom Lane wrote: > Alvaro Herrera 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 > > nge

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

2014-01-22 Thread Tom Lane
Alvaro Herrera 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

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

2014-01-22 Thread Alvaro Herrera
Christian Kruse wrote: I think this could use some more comments -- for instance at the top of the while loop, explain what's its purpose. > if (deadlock_state == DS_SOFT_DEADLOCK) > ereport(LOG, > (

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

2014-01-22 Thread Christian Kruse
Hi, On 22/01/14 12:40, Simon Riggs wrote: > > 1. I find a issue in following scenario: > > > > session 1 with process id X: BEGIN; LOCK TABLE foo IN SHARE MODE; > > session 2 with process id Y: BEGIN; LOCK TABLE foo IN EXCLUSIVE > > MODE; > > session 3 with process id Z: B

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

2014-01-22 Thread Simon Riggs
On 22 January 2014 04:42, Rajeev rastogi wrote: > > On 31st December 2013, Christian Kruse Wrote: > >> Hi there, >> >> I created two patches improving the log messages generated by >> log_lock_waits. The first patch shows the process IDs holding a lock we >> try to acquire (show_pids_in_lock_log.p

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

2014-01-21 Thread Rajeev rastogi
On 31st December 2013, Christian Kruse Wrote: > Hi there, > > I created two patches improving the log messages generated by > log_lock_waits. The first patch shows the process IDs holding a lock we > try to acquire (show_pids_in_lock_log.patch), sample output > (log_lock_waits=on required): >

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

2013-12-31 Thread Christian Kruse
Hi, On 31/12/13 08:48, Simon Riggs wrote: > > I created two patches.. > > Patches are related but separate, so should be tracked on separate > threads. [x] Done (in <20131231091244.gb25...@defunct.ch>) > Please add them to the CF app also. [x] Done. I modified the existing commitfest entry (

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

2013-12-31 Thread Simon Riggs
On 30 December 2013 19:52, Christian Kruse wrote: > I created two patches.. Patches are related but separate, so should be tracked on separate threads. Please add them to the CF app also. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Train

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

2013-12-30 Thread Christian Kruse
Hi there, I created two patches improving the log messages generated by log_lock_waits. The first patch shows the process IDs holding a lock we try to acquire (show_pids_in_lock_log.patch), sample output (log_lock_waits=on required): session 1: BEGIN; LOCK TABLE foo IN SHARE MODE; session 2: BEGI