[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
Attachments:
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 +0200Gerhard 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