Search Postgresql Archives

Re: (Never?) Kill Postmaster?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux