On Tue, Nov 29, 2016 at 4:56 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> New (9.4) XactLockTableWait() sets the reason for the wait, so that if
> we emit a log message then it will produce a log message to say its
> not waiting on a transaction, its waiting on a lock.
>
> Nice. log_lock_waits works great.
>
> New (9.6) wait_event code is not correctly set. In ProcSleep() we set
> the wait reason according to the actual lock tag, effectively ignoring
> the information specifically provided by XactLockTableWait().
>
The information provided by XactLockTableWait() helps to display the
more information via context, but the message still suggests
transaction (refer LOG line in below message):
LOG: process 6460 still waiting for ShareLock on transaction 42960
after 41822.775 ms
DETAIL: Process holding the lock: 5704. Wait queue: 6460.
CONTEXT: while updating tuple (0,1) in relation "t1"
STATEMENT: update t1 set c1=3 where c1=1;
So I am not sure if displaying tuple in pg_stat_activity is better
than displaying transactionid and how will we distinguish it when some
process is actually waiting on tuple lock? The process waiting on
tuple lock displays log message as below:
LOG: process 648 still waiting for ExclusiveLock on tuple (0,1) of
relation 137344 of database 12245 after 1045.220 ms
DETAIL: Process holding the lock: 6460. Wait queue: 648.
STATEMENT: update t1 set c1=4 where c1=1;
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com