Обсуждение: 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.