Recent runs of DBT-2 show very occasional ExclusiveLock (s) being held
by transactions, sometimes waiting to be granted.
On Sat, Nov 06, 2004 at 11:40:49AM +0000, Simon Riggs wrote:
> > The lockstats just show there's all those Exclusive Locks on
order_line, right?:
>
> http://www.osdl.org/projects/dbt2dev/results/dev4-010/191/db/lockstats.out
> >
>
> The output is...
> relname | pid | mode | granted
> ---------------+-------+------------------+---------
> new_order | 21735 | AccessShareLock | t
> new_order | 21735 | RowExclusiveLock | t
> orders | 21715 | AccessShareLock | t
> orders | 21715 | RowExclusiveLock | t
> pg_class | 23254 | AccessShareLock | t
> order_line | 21715 | AccessShareLock | t
> order_line | 21715 | RowExclusiveLock | t
> order_line | 21735 | ExclusiveLock | f
> new_order | 21715 | AccessShareLock | t
...
>
> which shows a non-granted lock, waiting for a Table-level
ExclusiveLock
> on order_line. This is unexpected
(by me, that is...)
According to the manual, Exclusive Lock is not normally held by SQL
statements. There are no LOCK TABLE statements in DBT-2.
My digging reveals that ExclusiveLock is held on user relations by_bt_getbuf() - when we extend a btree relation by one
page
I also find ExclusiveLock is held by
- LISTEN/NOTIFY
- XactLockTableInsert()/XactLockTableDelete()
but those don't look like they lock user relations
LockAcquire() says its locks show in lock tables, so is index extension
the source of the ExclusiveLocks shown in the lock output? Presumably
they would be short duration, so you wouldn't see them unless you caught
it at just the right moment....unless we start to queue up on the
leadingedge of the index.
I expect index extension to be a source of contention anyway, but are we
actually *seeing* it? Or is it another issue, and is this an 8.0
problem?
--
Best Regards, Simon Riggs
