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 were executing "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 the way 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! -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
