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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
