On 22 January 2014 04:42, Rajeev rastogi <rajeev.rastogi@huawei.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