Hi,
Thanks for the help.
The result by is:
acc01=# select * from pg_locks;
relation | database | transaction | pid | mode | granted
----------+----------+-------------+-------+-----------------+---------
16757 | 16976 | | 23169 | AccessShareLock | t
17062 | 16976 | | 1372 | AccessShareLock | t
17060 | 16976 | | 1372 | AccessShareLock | t
| | 116303 | 1372 | ExclusiveLock | t
| | 166846 | 23169 | ExclusiveLock | t
16995 | 16976 | | 1372 | AccessShareLock | t
17056 | 16976 | | 1372 | AccessShareLock | t
17038 | 16976 | | 1372 | AccessShareLock | t
(8 rows)
And only transaction 116303 is the problem.
Also it is production system with many transaction/sec and I am looking dor a
way to detect what query is in this transaction ( if possible).
The system is relativ big and it is dificult to detect this problem only from
transacton number, but we will read the code to find the bug.
At this point is is clear that we do not have pg bug and it is good news for
me.
regards,
ivan
Stephan Szabo wrote:
> On Tue, 11 Nov 2003, pginfo wrote:
>
> > Hi,
> > I can not be sure if it is not the case.
> > But we are usin this system on a number of servers and it happen only by
> > one.
> > Can I with a pg_locks help detect the query that is running?
>
> It won't directly tell you what statement is running (although my guess is
> also that it's probably something like an idle in transaction state
> backend), but it can tell you if that's the problem probably.
>
> You'd see something like:
> ...
> 21488 | 17057 | | 8613 | AccessShareLock | t
> ...
> 21488 | 17057 | | 8626 | AccessExclusiveLock | f
>
> Which is basically saying that the command in pid 8626 is waiting on the
> lock that pid 8613 has.