Re: stopping processes, preventing connections

Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> writes:
> On 17/03/2010 8:43 PM, Herouth Maoz wrote:
>> (gdb) backtrace
>> #0 0x8dfcb410 in ?? ()
>> #1 0xbff10a28 in ?? ()
>> #2 0x083b1bf4 in ?? ()
>> #3 0xbff10a00 in ?? ()
>> #4 0x8db98361 in send () from /lib/tls/i686/cmov/libc.so.6
>> #5 0x08195d54 in secure_write ()
>> #6 0x0819dc7e in pq_setkeepalivesidle ()
>> #7 0x0819ddd5 in pq_flush ()
>> #8 0x0819de3d in pq_putmessage ()
>> #9 0x0819fa63 in pq_endmessage ()
>> #10 0x08086dcb in printtup_create_DR ()
>> #11 0x08178dc4 in ExecutorRun ()
>> #12 0x08222326 in PostgresMain ()
>> #13 0x082232c0 in PortalRun ()
>> #14 0x0821e27d in pg_parse_query ()
>> #15 0x08220056 in PostgresMain ()
>> #16 0x081ef77f in ClosePostmasterPorts ()
>> #17 0x081f0731 in PostmasterMain ()
>> #18 0x081a0484 in main ()

> OK, so it seems to be stuck sending data down a socket.

Since this type of problem is fresh in mind: I wonder if the connection
is SSL-encrypted and the session just crossed the 512MB-total-data-sent
threshold. If so it would have tried to renegotiate session keys, and
some SSL vendors have recently broken that functionality rather badly.
Silent hangups seem to be par for the course.

If that's it, your choices are to find an SSL library that has an actual
fix for CVE-2009-3555 rather than this brain damage, or to update to
this week's PG releases so you can set ssl_renegotiation_limit to zero.

If you're not using SSL, just ignore me ...

regards, tom lane