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: