From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Gerhard Hintermayer <g.hintermayer@inode.at>
Cc: PostgreSQL-patches <pgsql-patches@postgresql.org>
Subject: Re: [INTERFACES] libpgtcl modifications
Date: Sat, 17 Aug 2002 08:19:35 -0400 (EDT)
Message-ID: <200208171219.g7HCJZk22900@candle.pha.pa.us> (raw)
In-Reply-To: <3D59F2F3.1030904@inode.at>
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Gerhard Hintermayer wrote:
> Bruce Momjian wrote:
> > Can I have some description of what this patch does?
> >
>
> Unfortunately some of my postings seem to vanish in cyberspace ;-)
>
> What I have done for libpgtcl:
> Everytime if I do PQconsumeInput (when the backend channel gets
> readable) I check for the return value. (0 == error) and generate a
> notification manually, e.g. fixed string connection_closed) and pass it to the
> TCL event queue. The only other thing I had to do is to comment out removing
> all pending events in PgStopNotifyEventSource whenever the connection was
> unexpectedly closed (so the manually generated event will not be deleted).
>
> A broken backend connection triggers a notify event to the client (fixed
> notification string "connection_closed") so proper action can be taken to switch
> to another database server etc. Remember that this is event driven. If you have
> applications, that have idle database connections most of the time, you'll get
> immediate feedback of a dying server. Upon connection to the server issue a
> pg_notify for notify event "connection_closed" and whenever the backend crashes
> (which it does do in very very rare cases) you get an event driven recovery. (of
> course the Tcl-Event loop has to be processed). Issuing a notification
> "connection_closed" on a still working database could be used for switching to
> another db-server (which I've actually impelemented right now).
>
> I did this not because we have crashing db-servers all the time, in fact we have
> running pg for many years without any major problems in a production environment
> (recipe and batch data for petfood production).
> One reason was to get notifications to applications, that run permanently and
> have a persistent db connection, in case the primary server should be changed
> for whatever reason (network problems, server shutdown, maintenance etc.)
>
> Gerhard.
>
> PS:
> >[ application/x-gunzip is not supported, skipping... ]
> are you joking, which file format do you suggest for a patch ?
>
>
> --
> Gerhard Hintermayer
> http://www.inode.at/g.hintermayer
>
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: pgman@candle.pha.pa.us, g.hintermayer@inode.at, pgsql-patches@postgresql.org
Subject: Re: [INTERFACES] libpgtcl modifications
In-Reply-To: <200208171219.g7HCJZk22900@candle.pha.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox