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

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
withprocess 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, YBut actually if we
seeY has not yet own the lock, it is still waiting with higher priority.It may mislead user.May be we should change
messageto give all meaning i.e. which process is owning lock andWhich process is already in queue. 

2. Can we give a better name to new variable 'buf1'?

3. Do we need to take performance reading to see if any impact?

4. Do we require documentation?


Thanks and Regards,
Kumar Rajeev Rastogi