Subject: [PATCHES] memory leak patches in libpq and psql
A couple of small memory leak patches (detected with Purify) primarily
in libpq.
* Fixed (NULL) border problem in psql (run psql, do \m, then select
something from a table...row separators will be nulls)
* Fixed memory leak with the abovementioned border not being freed
properly.
* Fixed memory leak in freePGconn() not freeing conn->port
* Fixed up PQclear() to free parts of PGresult only if these
parts are not null.
* Fixed a decent memory leak that occured after executing every command
in psql. PGresult *results was not freed most of the time.
There is still a leak being detected (2 bytes) in readline functions, but
I think this is old readline library. I will install new one and test it.
#if defined(aix)
#define TERMIOS_H_LOCATION <termios.h>
#else
#define TERMIOS_H_LOCATION <sys/termios.h>
#endif
libpq/fe-exec.c modified so that location of termios.h is determined
by whether HAVE_TERMIOS_H is defined or not, in preparation for switch
to configure
Hi,
counting the empty dummy queries in libpq isn't everything.
If the backend sends an error, the I returns from the dummies
still come. So we must eat them up in any case, not just
returning on the occurence of an E reply.
Until later, Jan
PQexec handles the possibility of multiple results from one
query by simply submitting an empty query after the first
result and waiting for an 'I' message.
Rules can generate errors with transaction abort after the
first 'C' message was recieved (e.g. if a C-language function
used in a rule calls elog(WARN, ...)). Thus we have to look
for.
Jan(wieck@sapserv.debis.de)
Async notifies received while a backend is in the middle of a begin/end
transaction block are lost by libpq when the final end command is issued.
The bug is in the routine PQexec of libpq. The routine throws away any
message from the backend when a message of type 'C' is received. This
type of message is sent when the result of a portal query command with
no tuples is returned. Unfortunately this is the case of the end command.
As all async notification are sent only when the transaction is finished,
if they are received in the middle of a transaction they are lost in the
libpq library. I added some tracing code to PQexec and this is the output:
Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>
|Here is a fix for the psql alignment problem. It turns out that libpq
|was trying to determine if the column contained only numeric values so
|it could right justify it. The 'e' values were taked as exponient
|values and all columns were considered numeric.
|
|The patch excludes 'e' and 'E' as being valid first-column numeric
|values.
|
Submitted by: Bruce...
|We're all too familiar with psql's "no response from backend" message.
|Users can't tell what this means, and psql continues prompting for
|commands after it even though the backend is dead and no commands can
|succeed. It eventually dies on a signal when the dead socket fills
|up. I extended the message to offer a better explanation and made
|psql exit when it finds the backend is dead.
|
|I also added a short message and newline when the user does a ctl-D so
|it doesn't mess up the terminal display.
|
|
Submitted by: Bryan Henderson <bryanh@giraffe.netgate.net>
Attached is a patch to allow libpq to determine if a field is null.
This is needed because text fields will return a PQgetlength() of 0
whether it is '' or NULL. There is even a comment in the source noting
the fact.
I have changed the value of the 'len' field for NULL result fields. If
the field is null, the len is set to -1 (NULL_LEN). I have changed
PQgetlength() to return a 0 length for both '' and NULL. A new function
PQgetisnull() returns true or false for NULL.
The only risk is to applications that do not use the suggested
PQgetlength() call, but read the result 'len' field directly.
As this is not recommended, I think we are safe here.
A separate documentation patch will be sent.
Submitted by: Bruce Momjian <maillist@candle.pha.pa.us>
Here are a few minor fixes to Postgres95. Mostly I have added const
to some of the char pointers. There was also a missing header file
and a place where it looks like "==" was used when "=" was meant.
I also changed some variables from Pfin and Pfout tp pfin and pfout
because the latter shadow global variables and that just seems like
an unsafe practice which I like to avoid.
Submitted by: "D'Arcy J.M. Cain" <darcy@druid.druid.com>
compatibility. There isn't much difference here against my previous
PQprint() code, except that you can add optional arguments to the
<table args> in html.
Most of the changes in here look to b epurely cosmetic, and don't
affect anything...
...and some stuff is completely questionable...in that I may have reversed
some of the stuf fwe already had :(
before (plus some optimisations/bug fixes et al). I've included a small
demo transcript below. Note that all of of the display
functionality/intelligence you see here, can be had merely by calling
the new LIBPQ PQprint() routine with the appropriate arguments/options,
including the HTML3 output guff.
submitted by: Julian Assange <proff@suburbia.net>
Thomas G. Lockhart
Bruce Momjian
Vadim B. Mikheev
Marc G. Fournier
Bryan Henderson
Julian Assange