Re: [Fwd: Tcl Interface modifications (Was: Re: database - Mailing list pgsql-general

From Brett Schwarz
Subject Re: [Fwd: Tcl Interface modifications (Was: Re: database
Date
Msg-id 1028734823.28352.3.camel@thor
Whole thread Raw
In response to [Fwd: Tcl Interface modifications (Was: Re: database shutdown with persistent client connections)]  (Gerhard Hintermayer <g.hintermayer@inode.at>)
List pgsql-general
On Tue, 2002-08-06 at 09:37, Gerhard Hintermayer wrote:
> Lost in space, here again:
>
> --
> Gerhard Hintermayer
> http://www.inode.at/g.hintermayer
> ----
>

> From: Gerhard Hintermayer <g.hintermayer@inode.at>
> Subject: Tcl Interface modifications (Was: Re: database shutdown with persistent client connections)
> Date: 05 Aug 2002 20:28:04 +0200
>
> Gerhard Hintermayer wrote:
> > tgl@sss.pgh.pa.us (Tom Lane) wrote in message news:<27612.1028124591@sss.pgh.pa.us>...
> >
> >>g.hintermayer@inode.at (Gerhard Hintermayer) writes:
> >>
> >>>Is there a notification sen't out in either smart or fast shutdown
> >>>mode ?
> >>
> >>Sure: the backend sends an error message
> >>  FATAL:  This connection has been terminated by the administrator.
> >>before closing the connection.
> >>
> >>The problem you're describing is that the client-side code isn't looking
> >>for any communication from the server except when it's involved in a SQL
> >>command.  I'm not sure what you can do about that except restructure the
> >>client.
> >>
> >
> >
> > What I tried is (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. connection_closed) and pass it to the TCL
> > event queue. The only bad thing I had to do is to comment out removing
> > all pending events in PgStopNotifyEventSource. Could there be any
> > sideeffects ? Maybe I should do that only if the connection was
> > unexpectedly closed (i.e. called from within PgNotifyTransferEvents) ?
> >
> > Gerhard
>
> Well, I hacked some files to get the following working:
>
> A broken backend connection trigers 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.
> I'd like to share my changes (because I don't want to apply them to every
> release). What's the way to go ?

I think you send them to the patches list?? It might also be better to
send this to the INTERFACES list.


> I'd also like to see a TclObj-based implementation, and also support for Tcl8.4
> (there are some incompatible API changes), *and* I'd even be willing to
> implement some of these changes.
> Any suggestions ?
>

I would definitely like to have your existing patch[*] in there, plus
make it object based. I started looking at doing this, but got side
tracked. I can help out if you need it...

    --brett


[*] I think PGAccess would benefit from this.

>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
--
Brett Schwarz
brett_schwarz AT yahoo.com


pgsql-general by date:

Previous
From: "Bolden, Thomas"
Date:
Subject: still lost: Cannot use more than 16 attributes in an index
Next
From: Neil Conway
Date:
Subject: Re: CREATE FUNCTION