connection shutdown. This is a grotty workaround for a Tcl bug, but
said bug has been there long enough that I'm not holding my breath
for a real fix. Per discussions and testing from ljb and g.hintermayer.
up to
reaching the hard limit. After opening 16(=current REST_START value)
results via pg_exec, the next pg_exec tries to find an empty slot
forever :-( . In PgSetResultId file pgtclId.c in the for loop there
has to be done a break, if res_max ist reached. The piece of code
should look like
if (resid == connid->res_max)
{
resid = 0;
break; /* the break as to be added */
}
now everything works (double available results after reaching
RES_START up to reaching RES_HARD_MAX)
Gerhard Hintermayer
seems we have a choice between annoying messages and leaking memory
(or dumping core, but that's right out). Patch also fixes several
other problems in pg_disconnect, such as being willing to close a
channel that isn't a PG channel.
Gerhard Hintermayer, revised and documented by Tom Lane.
This patch also fixes a 'must fix' bug: libpgtcl's LISTEN/NOTIFY
support was broken by the recent changes to the PGnotify structure.
Guess that change wasn't quite so safe as we thought.
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. fixed string connection_closed) and pass it to the
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. fixed string connection_closed) and pass it to the
TCL event queue. The only other thing I had to do is to comment out removing
all pending events in PgStopNotifyEventSource whenever the connection was
unexpectedly closed (so the manually generated event will not be deleted).
A broken backend connection triggers 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 (which I've actually impelemented right now).
Gerhard Hintermayer
>tcl-extension for postgreSQL.
>I'm currently using 7.0 and always getting a seg fault when I try to
>read from the database connection after issueing a "COPY table TO
>stdout;" (I'm using the connection handle, *not* the result handle).
>Maybe this is fixed in a later release.
>The README file in src/interfaces/libpgtcl tells me, that this should
>work, but unforunately it doesn't.
Yes, it seems broken. It is a bug in libpgtcl. Are you running Tcl >= 8.3.2?
That's when the Tcl team changed the data structure for channel
callbacks. The change itself was designed to be backward compatible, but I
suspect a related change made the code more sensitive to errors in the
structure (NULL pointers where functions are required). Either that, or
nobody has tried to use libpgtcl with COPY in a long time.
First, I have to say I can't think of a good reason to use PostgreSQL's
COPY command from a Tcl application. I think it should only be used with
psql for importing data from another source into PostgreSQL, or for
exporting PostgreSQL data into another database (but why would anyone do
that?) If it was me, I would stick with SELECT and INSERT and be "SQL
Compliant".
OK, editorial is over. Try applying the patch below to fix
src/interfaces/libpgtcl/pgtclId.c
and let us know if it works. I did little testing on it, but my test did
segfault before and ran fine (copy in and copy out) after the patch. This
is for PostgreSQL-7.1.2 - since you are running older 7.0, I don't know if
this will work, but I suspect it will.
PS It's the absence of PgWatchProc which kills it. I didn't upgrade it
to the "V2" channel type structure, so it should be compatible with older
Tcl's. But aside from gets and puts, I doubt any other file operations
would work on the handle during a copy.
ljb
two additional files win32.mak and libpgtcl.def.
This patch allows to compile libpgtcl.dll on Windows
with tcl > 8.0. I've tested it on WinNT (VC6.0), SUSE Linux (7.0)
and Solaris 2.6 with tcl 8.3.3.
Mikhail Terekhov
are now separate files "postgres.h" and "postgres_fe.h", which are meant
to be the primary include files for backend .c files and frontend .c files
respectively. By default, only include files meant for frontend use are
installed into the installation include directory. There is a new make
target 'make install-all-headers' that adds the whole content of the
src/include tree to the installed fileset, for use by people who want to
develop server-side code without keeping the complete source tree on hand.
Cleaned up a whole lot of crufty and inconsistent header inclusions.
* It works under both Tcl 7.6 and Tcl 8.0 now. (The code claims to
work under Tcl 7.5 as well, but I have no way to test that ---
if anyone still cares, please check it with 7.5.)
* pg_listen suppresses extra LISTEN commands and correctly sends an
UNLISTEN when the last listen request for a relation is cancelled.
(Note this means it will not work with pre-6.4 backends, but that
was true already because it depends on the current libpq, which
only speaks protocol 2.0.)
* Added -error option to pg_result so that there's some way to find
out what you did wrong ;-)
* Miscellaneous cleanups of code comments and overenthusiastic #includes.
BTW, I bumped the package version number from 1.2 to 1.3. Is this
premature? Does someone run around and do that routinely before
each pgsql release?
regards, tom lane
structs from libpq-fe.h, as we previously discussed.
There turned out to be sloppy coding practices in more places than
I had realized :-(, but all in all I think it was a well-worth-while
exercise.
I ended up adding several routines to libpq's API in order to respond
to application requirements that were exposed by this work. I owe the
docs crew updates for libpq.sgml to describe these changes. I'm way too
tired to work on the docs tonight, however.
This is the last major change I intend to submit for 6.4. I do want
to see if I can make libpgtcl work with Tcl 8.0 before we go final,
but hopefully that will be a minor bug fix.
with the new support for asynchronous NOTIFY in libpgtcl. With
the current sources, if the backend disconnects unexpectedly then
the tcl/tk application coredumps when control next reaches the idle
loop. Oops.
regards, tom lane
From: Tom Lane <tgl@sss.pgh.pa.us>
Attached is a patch for this weekend's work on libpq. I've dealt
with several issues:
<for details: see message, in pgsql-patches archive for above data>
pg_notifies statement is eliminated, and callbacks defined by
pg_listen are instead invoked automatically from the Tcl idle loop
whenever a NOTIFY message is received.
I have done only cursory testing, so there may be problems still
lurking (particularly on non-Unix machines?). But it seems to
work.
Patch is against today's cvs sources. Note that this will not work
with the 6.3.2 release since it depends on the new libpq.
The diffs are a bit large so I've gzipped them. A patch to update
libpgtcl.sgml is included too.
regards, tom lane
1. Rewritten libpq to allow asynchronous clients.
2. Implemented client side of cancel protocol in library,
and patched psql.c to send a cancel request upon SIGINT. The
backend doesn't notice it yet :-(
3. Implemented 'Z' protocol message addition and renaming of
copy in/out start messages. These are implemented conditionally,
ie, the client protocol version is checked; so the code should
still work with 1.0 clients.
4. Revised protocol and libpq sgml documents (don't have an SGML
compiler, though, so there may be some markup glitches here).
What remains to be done:
1. Implement addition of atttypmod field to RowDescriptor messages.
The client-side code is there but ifdef'd out. I have no idea
what to change on the backend side. The field should be sent
only if protocol >= 2.0, of course.
2. Implement backend response to cancel requests received as OOB
messages. (This prolly need not be conditional on protocol
version; just do it if you get SIGURG.)
3. Update libpq.3. (I'm hoping this can be generated mechanically
from libpq.sgml... if not, will do it by hand.) Is there any
other doco to fix?
4. Update non-libpq interfaces as necessary. I patched libpgtcl
so that it would compile, but haven't tested it. Dunno what
needs to be done with the other interfaces.
Have at it!
Tom Lane
It is my hope that the following "patches" to libpgtcl get included
in the next release.
See the update to the README file to get a full description of the changes.
This version of libpgtcl is completely interpreter-safe, implements the
database connection handle as a channel (no events yet, but will make it
a lot easier to do fileevents on it in the future), and supports the SQL
"copy table to stdout" and "copy table from stdin" commands, with the
I/O being from and to the connection handle. The connection and result
handles are formatted in a way to make access to the tables more efficient.
Adds:
-lAttributes
Returns another format of the results attribute list. Per
attribute a sublist of {{attname} atttype attlen} is
returned and an empty string if no attributes where
received.
-numAttrs
Returns the number of attributes in the result.
