Re: (Never?) Kill Postmaster? - Mailing list pgsql-general

From Christian Schröder
Subject Re: (Never?) Kill Postmaster?
Date
Msg-id 47373D30.5080302@deriva.de
Whole thread Raw
In response to Re: (Never?) Kill Postmaster?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: (Never?) Kill Postmaster?  (Martijn van Oosterhout <kleptog@svana.org>)
Re: (Never?) Kill Postmaster?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane wrote:
> =?ISO-8859-1?Q?Christian_Schr=F6der?= <cs@deriva.de> 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


pgsql-general by date:

Previous
From: Jorge Godoy
Date:
Subject: Re: any way for ORDER BY x to imply NULLS FIRST in 8.3?
Next
From: Martijn van Oosterhout
Date:
Subject: Re: (Never?) Kill Postmaster?