Re: query stuck at SOCK_wait_for_ready function call - Mailing list pgsql-general
| From | tamanna madaan |
|---|---|
| Subject | Re: query stuck at SOCK_wait_for_ready function call |
| Date | |
| Msg-id | 68666423656E1444A011106C4E085F4D96F2A1@ex3-del1.synapse.com Whole thread Raw |
| In response to | query stuck at SOCK_wait_for_ready function call ("tamanna madaan" <tamanna.madan@globallogic.com>) |
| List | pgsql-general |
Hi All
Now, I am using postgres-8.4.0 and psqlodbc-08.03.0400-1 and unixODBC-2.2.14-000.01 driver to connect
to the databse. Again having the same issue . One of the queries I executed from my application have got stuck for an
indefinite amount of time causing my application to hang. So I cored the application. The
core file gives a backtrace which shows it got stuck while waiting for a socket to get
ready as follows :
(gdb) bt
#0 0x00007f1c3e5ed366 in poll () from /lib64/libc.so.6
#1 0x00007f1c3a82d0a5 in SOCK_wait_for_ready (sock=0x7f1be67ff720, output=0, retry_count=1) at socket.c:531
#2 0x00007f1c3a82d8c3 in SOCK_get_next_byte (self=0x7f1be67ff720, peek=0) at socket.c:940
#3 0x00007f1c3a82db92 in SOCK_get_id (self=0x7f1be67ff720) at socket.c:696
#4 0x00007f1c3a8090ca in CC_send_query_append (self=0x7f1be68bf430, query=<value optimized out>, qi=0x0, flag=<value optimized out>, stmt=0x0,
appendq=<value optimized out>) at connection.c:2498
#5 0x00007f1c3a818ae5 in PGAPI_Transact (henv=0x0, hdbc=0x7f1be68bf430, fType=0) at execute.c:1143
#6 0x00007f1c3a8424ec in SQLEndTran (HandleType=<value optimized out>, Handle=0x7f1be68bf430, CompletionType=-1) at odbcapi30.c:178
#7 0x00007f1c3f62fa2b in SQLEndTran (handle_type=<value optimized out>, handle=0x7f1beff16b90, completion_type=0) at SQLEndTran.c:360
One other thread of the same process was also stuck :
(gdb) bt
#0 0x00007f1c3e5ed366 in poll () from /lib64/libc.so.6
#1 0x00007f1c3a82d0a5 in SOCK_wait_for_ready (sock=0x2bcde60, output=0, retry_count=1) at socket.c:531
#2 0x00007f1c3a82d8c3 in SOCK_get_next_byte (self=0x2bcde60, peek=0) at socket.c:940
#3 0x00007f1c3a82db92 in SOCK_get_id (self=0x2bcde60) at socket.c:696
#4 0x00007f1c3a8090ca in CC_send_query_append (self=0x2bd13a0, query=<value optimized out>, qi=0x0, flag=<value optimized out>, stmt=0x7f1bf766c380,
appendq=<value optimized out>) at connection.c:2498
#5 0x00007f1c3a836c94 in SC_execute (self=0x7f1bf766c380) at statement.c:1879
#6 0x00007f1c3a81907e in Exec_with_parameters_resolved (stmt=0x7f1bf766c380, exec_end=0x7f1c2c59e4c0) at execute.c:386
#7 0x00007f1c3a81a600 in PGAPI_Execute (hstmt=0x7f1bf766c380, flag=<value optimized out>) at execute.c:1070
#8 0x00007f1c3a83fd82 in SQLExecute (StatementHandle=0x7f1bf766c380) at odbcapi.c:374
#9 0x00007f1c3f630c77 in SQLExecute (statement_handle=0x7f1be4b069e0) at SQLExecute.c:283
I had the same issue while using postgres-8.1.2 and was advised to upgrade postgres.
But upgrading the postgres version didn't resolve the issue .
There doesn't seem to be any locking issue .
Can anyone please shed some light on this issue .
Thanks...
Tamanna
From: Alban Hertroys [mailto:dalroi@solfertje.student.utwente.nl]
Sent: Fri 12/31/2010 3:28 PM
To: tamanna madaan
Cc: Tom Lane; pgsql-general@postgresql.org
Subject: Re: [GENERAL] query stuck at SOCK_wait_for_ready function call
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:1210,4d1da969802651767083970!
pgsql-general by date: