On 31 Dec 2010, at 5:14, tamanna madaan wrote:
> Moreover, it cant be waiting for a lock as
> other processes were able to update the same table at the same time.
That only means it wasn't waiting on a TABLE-lock, occurrences of which are quite rare in Postgres. But if, for
example,an other update was updating the same row or if it was selected for update, then there would be a lock on that
row.
> restarting the process which was stuck because of this query, also
> resolved the issue. That means after restart, the process was able to
> update the same table.
After it restarted, was it updating the same row? If not, there's your explanation.
> Had it been waiting for a lock before , it wouldn't
> have been able to update the table after restart either.
It would have been able to, unless the table was being altered (ALTER TABLE foo ADD bar text) or some-such.
Did you upgrade to the latest minor release yet? Upgrading should be one of your first priorities for solving this
issue.
If you did and the problem still occurs; What is the query you were executing? From your backtrace it looks like you
wereexecuting "SELECT RUMaster(2) AS call_proc_result". If so, what does that function do?
You appear to be running Postgres on a Windows machine? Are you sure you don't have some anti-virus package getting in
theway locking files that are Postgres's?
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4d1da96f802651773617067!
