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