On Sun, Aug 11, 2013 at 9:25 PM, Josh Berkus <j...@agliodbs.com> wrote: > No, it's been a chronic issue since we got SMP support, pretty much > forever. Why do you think we have pg_terminate_backend()? > > The problem, as explored downthread, is that there's no clear way to fix > this. It's a problem which goes pretty far beyond PostgreSQL; you can > experience the same issue on Apache with stuck downloads.
No. There are multiple problems that can cause a stuck orphaned server process and I think you're conflating different kinds of problems. a) If the client dies due to C-c or kill or any other normal exit path. There's really no excuse for not detecting that situation *immediately*. As suggested in the original post the client could notify the server before it dies that it's about to die. b) If the client dies in some abnormal path such as kill -9. In that case we could easily detect the situation as quickly as we want but the more often we probe the more time we waste and cpu wakeups we waste sending probes. We would only need to react to errors on that connection (RST packets which will cause a SIGIO or eof depending on what we ask for), not a lack of response so it doesn't need to make things more fragile. c) If the client goes away either because it's turned off or the network is disconnected. This is the problem Apache faces because it's exposed to the internet at large. We're not entirely immune to it but we have much less of a problem with it. The problem here is that there's really no easy solution at all. If you send keep-alives and time them out then transient network connections become spurious fatal errors. > Our advantage over MySQL is that the idle process isn't likely to crash > anything ... -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
