From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, testperf-general(at)pgfoundry(dot)org |
Subject: | Re: ExclusiveLock |
Date: | 2004-11-08 21:37:15 |
Message-ID: | 10763.1099949835@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> Recent runs of DBT-2 show very occasional ExclusiveLock (s) being held
> by transactions, sometimes waiting to be granted.
I think you are right that these reflect heap or btree-index extension
operations. Those do not actually take locks on the *table* however,
but locks on a single page within it (which are completely orthogonal to
table locks and don't conflict). The pg_locks output leaves something
to be desired, because you can't tell the difference between table and
page locks.
It's odd that your example does not appear to show someone else holding
a conflicting lock.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2004-11-08 22:02:58 | Re: Increasing the length of pg_stat_activity.current_query... |
Previous Message | Tom Lane | 2004-11-08 21:00:15 | Re: Increasing the length of pg_stat_activity.current_query... |