Tom Lane wrote:
=?ISO-8859-1?Q?Christian_Schr=F6der?= <cs@xxxxxxxxx> writes:
Although I do not yet have any processes that are stuck inside a
statement, there are some that are idle, but do not respond to SIGINT or
even SIGTERM. Is this sufficient?
Dunno. Have you looked at their call stacks with gdb?
(gdb) bt
#0 0x00002b24aeee0a68 in __lll_mutex_lock_wait () from
/lib64/libpthread.so.0
#1 0x00002b24aeedde88 in pthread_rwlock_rdlock () from
/lib64/libpthread.so.0
#2 0x00002b24a5814e23 in _nl_find_msg () from /lib64/libc.so.6
#3 0x00002b24a5815c83 in __dcigettext () from /lib64/libc.so.6
#4 0x00002b24a585df0b in strerror_r () from /lib64/libc.so.6
#5 0x00002b24a585dd33 in strerror () from /lib64/libc.so.6
#6 0x00000000005f4daa in expand_fmt_string ()
#7 0x00000000005f6d14 in errmsg ()
#8 0x00000000005185f3 in pq_recvbuf ()
#9 0x0000000000518987 in pq_getbyte ()
#10 0x000000000057eb69 in PostgresMain ()
#11 0x0000000000558218 in ServerLoop ()
#12 0x0000000000558db8 in PostmasterMain ()
#13 0x000000000051a213 in main ()
Seems to be the same as for the processes that were stuck inside of a
statement.
I recompiled the server with debugging symbols enabled and then did the
following experiment: I started a query which I knew would take some
time. While the query executed I disconnected my dial-up line. After
reconnecting the backend process was still there (still SELECTing).
Meanwhile the query is finished and the process is idle, but it's still
present. I tried to "kill -SIGINT" the process and it didn't respond.
"pg_cancel_backend" also didn't work. However, a "kill -SIGTERM" did
kill the process (in contrast to the processes I saw before) and the
call stack is different:
(gdb) bt
#0 0x00002ac5d1d0f0c5 in recv () from /lib64/libc.so.6
#1 0x0000000000514292 in secure_read (port=0x996730, ptr=0x917760,
len=8192) at be-secure.c:313
#2 0x0000000000518574 in pq_recvbuf () at pqcomm.c:723
#3 0x0000000000518987 in pq_getbyte () at pqcomm.c:764
#4 0x000000000057eb69 in PostgresMain (argc=4, argv=0x97f830,
username=0x97f6d0 "chschroe") at postgres.c:301
#5 0x0000000000558218 in ServerLoop () at postmaster.c:2934
#6 0x0000000000558db8 in PostmasterMain (argc=3, argv=0x97bfd0) at
postmaster.c:966
#7 0x000000000051a213 in main (argc=3, argv=0x97bfd0) at main.c:188
I now did the same again and will wait some time. Maybe the process will
come to the same state the other processes had been. If not, I'm pretty
sure that my users will be able to create some really persistent
processes again ... ;-)
Regards,
Christian
--
Deriva GmbH Tel.: +49 551 489500-42
Financial IT and Consulting Fax: +49 551 489500-91
Hans-Böckler-Straße 2 http://www.deriva.de
D-37079 Göttingen
Deriva CA Certificate: http://www.deriva.de/deriva-ca.cer
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
