Subject: [PATCHES] pg_dump memory leak patch
This patch fixes a HUGE memory leak problem in pg_dump.
Pretty much anything that was allocated was never freed and Purify
reported about 40% possible memory leak and 6% actual leak. I added
functions to clear out all the allocated structures. After the patch
Purify returns 0 for number of bytes leaked...
Subject: [PATCHES] Three small patches.
Hi,
Here are 3 small patches to the postgreSQL source sup'd on
the 6th May 1997.
The 1st 2 fix the shell backslash "c" handling used to suppress
the newline on some unix shells. (The \c needs to be inside quote.)
The 3rd may or may not be the correct way to fix the missing
define of INDEX_MAX_KEYS in pg_dump.h
FreeBSD
The Makefile(s) have all been cleaned up such that there is a single
LDFLAGS vs LD_ADD or LDADD or LDFLAGS or LDFLAGS_BE. The Makefile(s)
should be alot more straightforward then they were before...and
consistent
Add a check to configure for strdup
Remove all the '-ltermcap' checks from psql/Makefile
Have {psql,pg_dump}/Makefile modified if strdup doesn't exist on the system
|by neglecting to quote them.
|
|I have made a minor change to pg_dump.c that will fix this.
|
|Dates are dumped and restored OK with pg_dump in V6
|
|We'll still need to fix the dump in both cases if the original dump is from V1.09.
From Keith Parks
It adds a WITH OIDS option to the copy command, which allows
dumping and loading of oids.
If a copy command tried to load in an oid that is greater than
its current system max oid, the system max oid is incremented. No
checking is done to see if other backends are running and have cached
oids.
pg_dump as its first step when using the -o (oid) option, will
copy in a dummy row to set the system max oid value so as rows are
loaded in, they are certain to be lower than the system oid.
pg_dump now creates indexes at the end to speed loading
Submitted by: Bruce Momjian <maillist@candle.pha.pa.us>
pg_dump and load to 2.0. I haven't gotten any feedback on whether
people want it, so I am submitting it for others to decide. I would
recommend an install in 1.02.1.
I had said that the 2.0 pg_dump could dump a 1.02.1 database, but I was
wrong. The copy is actually performed by the backend, and the 2.0
database will not be able to read 1.02.1 databases because of the new
system columns.
This patch does several things. It copies nulls out as \N, so they can
be distinguished from '' strings. It fixes a problem where backslashes
in the input stream were not output as double-backslashes. Without this
patch, backslashes copied out were deleted upon input, or interpreted as
special characters. Third, input is now terminated by backslash-period.
This can not be part of a normal input stream.
I tested this by creating a database with all sorts of nulls, backslash,
and period fields and dumped the database and reloaded into a new
database and compared them.
Submitted by: Bruce
case where the attribute length is variable (stored as -1). Previously,
you'd get output that looked like:
CREATE TABLE foo (bar varchar(-1));
Monitor and psql don't like this at all :). Here is a fix:
Submitted by: Adam Sussman <myddryn@vidya.com>