On 11/11/08 9:09 PM, "Tom Lane" <tgl@xxxxxxxxxxxxx> wrote: > Glen Beane <Glen.Beane@xxxxxxx> writes: >> On 11/11/08 2:25 PM, "Tom Lane" <tgl@xxxxxxxxxxxxx> wrote: >>> The most direct evidence about why it's stuck would probably be had by >>> attaching to the backend process with gdb and getting a stack trace. > >> It wasn't built with debugging symbols so there is some missing info, but >> here is what I get if I attach with gdb: > >> (gdb) where >> #0 0xb7f63410 in __kernel_vsyscall () >> #1 0xb7ac9273 in read () from /lib/tls/i686/cmov/libc.so.6 >> #2 0xb7d42d37 in ?? () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 >> #3 0x081a1226 in ?? () >> #4 0xb7d40db1 in BIO_read () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 >> #5 0xb7e05362 in ssl3_read_n () from /usr/lib/i686/cmov/libssl.so.0.9.8 >> #6 0xb7e05b2e in ssl3_read_bytes () from /usr/lib/i686/cmov/libssl.so.0.9.8 >> #7 0xb7e03096 in ssl3_read () from /usr/lib/i686/cmov/libssl.so.0.9.8 >> #8 0xb7e13b78 in SSL_read () from /usr/lib/i686/cmov/libssl.so.0.9.8 >> #9 0x081a128a in secure_read () >> #10 0x081a94c1 in ?? () >> #11 0x081a95d9 in pq_getbytes () >> #12 0x081a9744 in pq_getmessage () >> #13 0x0813853c in ?? () >> #14 0x0813883a in ?? () >> #15 0x08138a05 in ?? () >> #16 0x0813b456 in DoCopy () > > Well, this is sufficient to draw a conclusion: it's waiting for the > client to send it some more COPY data. So next you need to look into > what the client's state is. What software are you using on the client > side, anyway? Python with the psycopg2 library. I swear this was working earlier today. Maybe I am imagining things :) It does work with a unix socket, and I have a deadline to meet, so for now I just need to make sure I am running this on the same host as the postgresql server -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
