From: | Gerhard Hintermayer <g(dot)hintermayer(at)inode(dot)at> |
---|---|
To: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: libpgtcl modifications |
Date: | 2002-08-23 04:30:09 |
Message-ID: | 3D65BA51.20008@inode.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-interfaces pgsql-patches |
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
Attachment | Content-Type | Size |
---|---|---|
patch_conn_loss.gz | application/x-gunzip | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2002-08-23 08:19:49 | pgsql-server/contrib/pgstattuple README.pgstat ... |
Previous Message | Bruce Momjian - CVS | 2002-08-23 04:27:19 | pgsql-server/doc/src/sgml syntax.sgml |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Copeland | 2002-08-23 12:47:56 | Re: [HACKERS] ODBC Driver moved to GBorg ... |
Previous Message | Marc G. Fournier | 2002-08-22 22:46:03 | ODBC Driver moved to GBorg ... |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-08-23 04:35:43 | Re: Point in time recovery 20020822_01_pitr.patch |
Previous Message | Tom Lane | 2002-08-23 04:29:42 | Re: Point in time recovery 20020822_01_pitr.patch |