Thread: [Fwd: Tcl Interface modifications (Was: Re: database shutdown with persistent client connections)]

Lost in space, here again:

--
Gerhard Hintermayer
http://www.inode.at/g.hintermayer
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'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 ?

Gerhard

--
Gerhard Hintermayer
http://www.inode.at/g.hintermayer

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