From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com> |
Cc: | Christian Kruse <christian(at)2ndquadrant(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 11:40:35 |
Message-ID: | CA+U5nMJi=1nYAWKH5LmyaDC+zMNx_cSuKZXYg_J6uV9xQgaAUA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 22 January 2014 04:42, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com> 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.patch), sample output
>> (log_lock_waits=on required):
>>
>> session 1: BEGIN; LOCK TABLE foo IN SHARE MODE; session 2: BEGIN; LOCK
>> TABLE foo IN SHARE MODE; session 3: BEGIN; LOCK TABLE foo IN EXCLUSIVE
>> MODE;
>>
>> Output w/o patch:
>>
>> LOG: process 13777 still waiting for ExclusiveLock on relation 16385
>> of database 16384 after 1000.030 ms
>>
>> Output with patch:
>>
>> LOG: process 13777 still waiting for ExclusiveLock on relation 16385
>> of database 16384 after 1000.030 ms
>> CONTEXT: processes owning lock: 13775, 13776
>
> I am reviewing this patch. The idea seems to be reasonable.
> Following are my first level observation:
>
> 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: BEGIN; LOCK TABLE foo IN SHARE MODE;
>
> On execution of LOCK in session-3, as part of log it will display as:
> processes owning lock: X, Y
> But actually if we see Y has not yet own the lock, it is still waiting with higher priority.
> It may mislead user.
> May be we should change message to give all meaning i.e. which process is owning lock and
> Which process is already in queue.
Perhaps this?
CONTEXT: lock owner XXXX request queue XXX, XXX, XXX, etc
> 2. Can we give a better name to new variable 'buf1'?
>
> 3. Do we need to take performance reading to see if any impact?
Don't think so. Diagnosing problems will help performance, not hinder it
> 4. Do we require documentation?
Don't think so.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Yugo Nagata | 2014-01-22 11:44:31 | Re: Proposal: variant of regclass |
Previous Message | Tatsuo Ishii | 2014-01-22 11:04:12 | Re: Proposal: variant of regclass |