Thread: query stuck at SOCK_wait_for_ready function call

On 30/12/2010 10:28, tamanna madaan wrote:
> Hi All
>
> I am using postgres-8.1.2 and have been using psqlodbc-08.03.0200 driver to connect

I'd imagine you're going to get a *flood* of responses saying this, but
here goes anyway - the version of Postgres you're using is VERY old, and
missing 21 sets of bug fixes; the 8.1 branch is up to 8.1.23. In fact,
to my knowledge the entire 8.1 branch is end-of-life; certainly on
Windows anyway.

I can't shed any light on your problem, but you should certainly upgrade
if you can, as there's a fair chance that your problem might arise from
a bug fixed in a later version.

Ray.


--
Raymond O'Donnell :: Galway :: Ireland
rod@iol.ie

"tamanna madaan" <tamanna.madan@globallogic.com> writes:
> I am using postgres-8.1.2 and have been using psqlodbc-08.03.0200 driver to connect
> to the databse. One of the queries I executed from my appilcation have got stuck for an
> indefinite amount of time causing my application to hang.

Are you sure you didn't simply issue a very long-running query?  Or one
that is waiting for a lock?

            regards, tom lane

Thanks Tom for your reply .

However, This is not a very long running query.
This was supposed to update only one row in a table.
Moreover, it cant be waiting for a lock as
other processes were able to update the same table at the same time.
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. Had it been waiting for a lock before , it wouldn't
have been able to update the table after restart either.


Regards
Tamanna


-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Thu 12/30/2010 11:23 PM
To: tamanna madaan
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] query stuck at SOCK_wait_for_ready function call

"tamanna madaan" <tamanna.madan@globallogic.com> writes:
> I am using postgres-8.1.2 and have been using psqlodbc-08.03.0200 driver to connect
> to the databse. One of the queries I executed from my appilcation have got stuck for an
> indefinite amount of time causing my application to hang.

Are you sure you didn't simply issue a very long-running query?  Or one
that is waiting for a lock?

                        regards, tom lane

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!

On Fri, Dec 31, 2010 at 09:44:43AM +0530, tamanna madaan wrote:

> However, This is not a very long running query.
> This was supposed to update only one row in a table.

That it's supposed to update only one row does not mean it wasn't a
very long running query.

> Moreover, it cant be waiting for a lock as
> other processes were able to update the same table at the same time.

I don't see how that follows.  Postgres doesn't normally lock the
whole table.

> 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. Had it been waiting for a lock before , it wouldn't
> have been able to update the table after restart either.

I don't think that's true.  If you restarted, you killed all the
outstanding operations.  If something previously had a lock that was
blocking your query, that lock was removed.  Now your query can go
through.

In order to know whether there is a problem with a lock, you can use
the pg_locks system view.  Documentation is in the manual:
http://www.postgresql.org/docs/9.0/interactive/view-pg-locks.html (or,
for your release,
http://www.postgresql.org/docs/8.1/interactive/view-pg-locks.html).

By the way, the advice you got yesterday about upgrading is good
advice.  I wouldn't keep running the version you're running.

A

--
Andrew Sullivan
ajs@crankycanuck.ca