| From: | Christian Kruse <christian(at)2ndquadrant(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire |
| Date: | 2014-02-01 10:41:54 |
| Message-ID: | 20140201104154.GD12556@defunct.ch |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 01/02/14 02:45, Fujii Masao wrote:
> LOG: process 33662 still waiting for ShareLock on transaction
> 1011 after 1000.184 ms
> DETAIL: Process holding the lock: 33660. Request queue: 33662.
> [… snip …]
> LOG: process 33665 still waiting for ExclusiveLock on tuple (0,4)
> of relation 16384 of database 12310 after 1000.134 ms
> DETAIL: Process holding the lock: 33662. Request queue: 33665
>
> This log message says that the process 33662 is holding the lock, but
> it's not true.
As the message says: first lock is waiting for the transaction, second
one for the tuple. So that are two different locks thus the two
different holders and queues. So…
> Is this the intentional behavior?
Yes, I think so.
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oskari Saarenmaa | 2014-02-01 11:29:39 | Re: [PATCH] pg_basebackup: progress report max once per second |
| Previous Message | Christian Kruse | 2014-02-01 10:28:08 | Re: [bug fix] pg_ctl fails with config-only directory |