pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Gerhard Hintermayer <g.hintermayer@inode.at>
To: pgsql-interfaces@postgresql.org
Subject: Re: libpgtcl modifications
Date: Thu, 22 Aug 2002 21:30:09 -0700
Message-ID: <3D65BA51.20008@inode.at> (raw)
References: <bd4db85f.0208120116.7fa08c3f@posting.google.com>

Revision 2 was not so quick, but also not so dirty. Here's my first draft.
I have modified:
- Version number of Pgtcl changed to 1.4 (to reflect the additional command)
- added a command pg_on_connection_loss
   Syntax: pg_on_connection_loss conn ?callback?
   Use no callback parameter to query the actuall callback script and 
with parameter to set/change callback. The callback is evaluated 
whenever the connection to the backend gets lost (eof condition ?).

I do this by checking for a false return value from PQconsumeInput. 
Today I did some quick testing, no segfaults, no errors. Broken backends 
are detected both in idle connections and when you're in a COPY command 
(these are the two possibilities, where PQconsumeInput is called).
I'm using the same readable fileevent on the database connection as 
pg_listen does internally. The structure Pg_ConnectionId was extended by 
two fields : char *conn_loss to store the callback and Tcl_Interp 
*interp to store the interpreter, in which context the callback will be 
  evaluated.
Can someone with more experience on Tcl event programming take a look at 
this, I mananged to write some Tcl extensions, but am new to modifying 
the Tcl event-loop. (what I did, was copying most of the pg_listen stuff).
Basically  PgStartNotifyEventSource() is called, when a callback proc is 
supplied to pg_on_connection_loss, which (unmodified) does install a 
readable fileevent on the db connection, then I check for false return 
value of PQconsumeInput and add a ConnLossEvent type to the event queue.
(pg_)listen callbacks are deleted immediately from the the event queue 
when the db connection is broken, just like in the unpatch version. What 
  This a point worth to discuss: Which commands will dump core when used 
in the disconnect handler ? pg_disconnect works, but the best thing 
might be to invoke pg_disconnect as the first command  within the 
disconnect handler per default (in C code, not in Tcl) so possible 
subsequent operations on the just closed connection would at least 
trigger a "... is not a valid postgresql connection" error, but not run 
into any segfaults.

I will do some more testing tomorrow, but since I only can post via 
google at work, I'd like to get some feedback more quickly.

Gerhard

PS: I need my patch also for an older version of Postgresql (7.0.2), can 
I copy the whole libpgtcl directory into the 7.0.2 source path without 
any risk ?

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

Attachments:

  patch_conn_loss.gz (application/x-gunzip, 1.8K) download

view thread (13+ messages)  latest in thread

Message-ID: <3D65BA51.20008@inode.at>
Permalink:  ../3D65BA51.20008@inode.at/
Also on:    postgresql.org/message-id/3D65BA51.20008@inode.at

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-interfaces@postgresql.org
  Cc: g.hintermayer@inode.at
  Subject: Re: libpgtcl modifications
  In-Reply-To: <3D65BA51.20008@inode.at>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox