Thread: How does an application recognize the death of the postmaster
How do folks handle the death of the postmaster in their applications? Assuming the postmaster dies after an application has connected to the database, but before it makes a request. What should I look for? Currently our application that's in development does not handle the situation well. What we want to do is gracefully (as possible) shutdown the application. -- Until later, Geoffrey Any society that would give up a little liberty to gain a little security will deserve neither and lose both. - Benjamin Franklin
On Wed, May 03, 2006 at 02:44:03PM -0400, Geoffrey wrote: > How do folks handle the death of the postmaster in their applications? > Assuming the postmaster dies after an application has connected to the > database, but before it makes a request. What should I look for? > Currently our application that's in development does not handle the > situation well. What we want to do is gracefully (as possible) shutdown > the application. 90% of our code, and all of the critical engines, is written in ruby. Some legacy code is in python. Both of these languages handle exceptions extremely well: When a database connection goes away, an exception gets thrown the next time it tries to access the database. If the application does nothing, the environment (language interpreter and libraries) release memory, file handles, sockets, etc. without our code having to doing anything, and then exits with an error code and a stack trace. All of this is done for us without writing any code to do it -- it just comes with the environment. We can (and often do) catch the exception just to print a nicer message (stack traces are programmer friendly but ugly), or to clean up the rare resource that the libraries don't know about, but it's seldom more than a few lines of code. We don't have to think about it much. Best Regards, Wayne Conrad
Geoffrey wrote: > How do folks handle the death of the postmaster in their applications? > Assuming the postmaster dies after an application has connected to the > database, but before it makes a request. What should I look for? > Currently our application that's in development does not handle the > situation well. What we want to do is gracefully (as possible) > shutdown the application. Really depends on your run-time environment. Running Java under the JBoss app server or the Tomcat servlet container, you can configure data sources so that they test a connection before parceling them out to applications. If a pooled connection has gone dead, the container will discard it and get another one for you. That will allow you application to be blissfully unaware of momentary glitches. However, that obviously won't help if your database is down hard for an extended period. Both containers can be configured to give up trying and return an error to your app. -- Guy Rouillier
It does not get mail for a long time. ;^) It also can not establish a connection to the listener. If you are on the same machine as the db, you could check to see if the process is running. You could also setup an inetd listener that indicates the status of the postmaster. I have not done that in a long time, but should be fairly simple and using tcpwrappers you can make it reasonably safe.
Geoffrey wrote: > How do folks handle the death of the postmaster in their applications? > Assuming the postmaster dies after an application has connected to the > database, but before it makes a request. What should I look for? > Currently our application that's in development does not handle the > situation well. What we want to do is gracefully (as possible) > shutdown the application. > you should provide a bit more information regarding your application... is it C code, PHP, RUBY, etc. Each of these would have different solutions. As already mentioned, some already have handling code that throws errors. Others may require a bit more work on your part to recognize and handle the situation.