Re: [INTERFACES] libpgtcl modifications

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Gerhard Hintermayer <g(dot)hintermayer(at)inode(dot)at>
Cc: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [INTERFACES] libpgtcl modifications
Date: 2002-08-17 12:19:35
Message-ID: 200208171219.g7HCJZk22900@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-interfaces pgsql-patches


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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian - CVS 2002-08-17 12:33:18 pgsql-server/ oc/src/sgml/libpq.sgml rc/interf ...
Previous Message Bruce Momjian - CVS 2002-08-17 12:19:32 pgsql-server/src/interfaces/libpgtcl pgtclCmds ...

Browse pgsql-interfaces by date

  From Date Subject
Next Message Warren W. Gay VE3WWG 2002-08-17 16:20:15 Re: libpq bug handling signals
Previous Message Warren W. Gay VE3WWG 2002-08-17 04:56:31 Transaction Abort State?

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2002-08-17 12:33:37 Re: connect_timeout parameter in libpq
Previous Message Bruce Momjian 2002-08-17 12:15:38 Re: improve SET CONSTRAINTS