Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

There is no obvious way of tracking down all these situations, but we can offer a query which will allow us to generate a "signature" for the requests that cause the problems. This is done using the following SQL:

Code Blockpanel

SELECT

relation,

transaction,

pid,

mode,

granted,

relname


FROM

pg_locks


INNER

JOIN

pg_stat_user_tables


ON

pg_locks.relation

=

pg_stat_user_tables.relid


WHERE

pg_locks.pid='

[

pid

]

';

This will give us a list of table names that a given process (identified by its pid) has locked and not released. This will hopefully allow us to identify which requests are causing the problem. Therefore, if you run this query, you should be able to see if this is your own code (accessing, for example, your tables, or a set of tables that one of your operations uses) or whether it is a DSpace bug. You should post this signature to the mailing list if you can't debug it yourself.

For example, this is an output from the above query:

...


relation

...

transaction

pid

mode

granted

relname

18034

 

4909

AccessShareLock

t

group2groupcache

18113

 

4909

AccessShareLock

t

metadatavalue

18046

 

4909

AccessShareLock

t

item

18008

 

4909

AccessShareLock

t

eperson

18248

 

4909

AccessShareLock

t

handle

18235

 

4909

AccessShareLock

t

epersongroup2eperson

So process 4909 has AccessShareLocks on 6 tables, and these 6 tables should help us identify where to look for the bug. In this case it is particularly unclear, but a process which uses groups, epersons, items handles and metadata is probably a deposit process.

...

which produces something like:

...

datid

...

datname

...

procpid

...

usesysid

...

usename

...

current_query

...

query_start

17142

...

dspace

...

1107

...

1

...

dsprd

...

<IDLE>

...

2007-06-11 11:21:36.147423+01

17142

...

dspace

...

1401

...

1

...

dsprd

...

<IDLE>

...

2007-06-11 11:22:41.730301+01

17142

...

dspace

...

25163

...

1

...

dsprd

...

<IDLE>

...

2007-06-11 11:21:36.097556+01

17142

...

dspace

...

27973

...

1

...

dsprd

...

update history set creation_date = '...'

...

2007-06-11 11:25:39.687193+01

17142

...

dspace

...

916

...

1

...

dsprd

...

<IDLE>

...

2007-06-11 11:21:32.759784+01

Combining queued queries with locks

...