Re: How does an application recognize the death of the

Lists: pgsql-general
From: Geoffrey <esoteric(at)3times25(dot)net>
To: PostgreSQL List <pgsql-general(at)postgresql(dot)org>
Subject: How does an application recognize the death of the postmaster
Date: 2006-05-03 18:44:03
Message-ID: 4458F9F3.9000208@3times25.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

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


From: Wayne Conrad <wconrad(at)yagni(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: How does an application recognize the death of the postmaster
Date: 2006-05-03 18:57:01
Message-ID: 20060503185701.GA26821@mail.yagni.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

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


From: Guy Fraser <guy(at)incentre(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: How does an application recognize the death of the
Date: 2006-05-03 20:28:25
Message-ID: 1146688105.4540.67.camel@sigurd.incentre.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

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.


From: Reid Thompson <reid(dot)thompson(at)ateb(dot)com>
To: Geoffrey <esoteric(at)3times25(dot)net>
Cc: PostgreSQL List <pgsql-general(at)postgresql(dot)org>
Subject: Re: How does an application recognize the death of the
Date: 2006-05-04 12:49:19
Message-ID: 4459F84F.2050708@ateb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

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.