Marc G. Fournier [Thu, 13 Feb 1997 08:06:36 +0000 (08:06 +0000)]
Patch for:
The following patch to src/backend/libpq/pqpacket.c provides additional
checking for bad packet length data. It was tested with the Linux telnet
client, with netcat using the numbers.txt and by dumping random numbers
into the port.
Marc G. Fournier [Wed, 12 Feb 1997 05:25:13 +0000 (05:25 +0000)]
Patch from Massimo Dal Zotto <dz@cs.unitn.it>
The following patches add to the backend a new debugging flag -K which prints
a debug trace of all locking operations on user relations (those with oid
greater than 20000). The code is compiled only if LOCK_MGR_DEBUG is defined,
so the patch should be harmless if not explicitly enabled.
I'm using the code to trace deadlock conditions caused by application queries
using the command "$POSTMASTER -D $PGDATA -o '-d 1 -K 1'.
The patches are for version 6.0 dated 970126.
Marc G. Fournier [Wed, 12 Feb 1997 05:04:52 +0000 (05:04 +0000)]
What looks like some *major* improvements to btree indexing...
Patches from: aoki@CS.Berkeley.EDU (Paul M. Aoki)
i gave jolly my btree bulkload code a long, long time ago but never
gave him a bunch of my bugfixes. here's a diff against the 6.0
baseline.
for some reason, this code has slowed down somewhat relative to the
insertion-build code on very small tables. don't know why -- it used
to be within about 10%. anyway, here are some (highly unscientific!)
timings on a dec 3000/300 for synthetic tables with 10k, 100k and
1000k tuples (basically, 1mb, 10mb and 100mb heaps). 'c' means
clustered (pre-sorted) inputs and 'u' means unclustered (randomly
ordered) inputs. the 10k table basically fits in the buffer pool, but
the 100k and 1000k tables don't. as you can see, insertion build is
fine if you've sorted your heaps on your index key or if your heap
fits in core, but is absolutely horrible on unordered data (yes,
that's 7.5 hours to index 100mb of data...) because of the zillions of
random i/os.
if it doesn't work for you for whatever reason, you can always turn it
back off by flipping the FastBuild flag in nbtree.c. i don't have
time to maintain it.
good luck!
baseline code:
time psql -c 'create index c10 on k10 using btree (c int4_ops)' bttest
real 8.6
time psql -c 'create index u10 on k10 using btree (b int4_ops)' bttest
real 9.1
time psql -c 'create index c100 on k100 using btree (c int4_ops)' bttest
real 59.2
time psql -c 'create index u100 on k100 using btree (b int4_ops)' bttest
real 652.4
time psql -c 'create index c1000 on k1000 using btree (c int4_ops)' bttest
real 636.1
time psql -c 'create index u1000 on k1000 using btree (b int4_ops)' bttest
real 26772.9
bulkloading code:
time psql -c 'create index c10 on k10 using btree (c int4_ops)' bttest
real 11.3
time psql -c 'create index u10 on k10 using btree (b int4_ops)' bttest
real 10.4
time psql -c 'create index c100 on k100 using btree (c int4_ops)' bttest
real 59.5
time psql -c 'create index u100 on k100 using btree (b int4_ops)' bttest
real 63.5
time psql -c 'create index c1000 on k1000 using btree (c int4_ops)' bttest
real 636.9
time psql -c 'create index u1000 on k1000 using btree (b int4_ops)' bttest
real 701.0
Essentially, config.h now includes an 'os.h', which is created via
configure by linking a "port.h" file from the port directory to the
include directory.
Going to try to merge backend/port in similar ways
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
|I took a look at this and I think pg_dump mishandles arrays of ints and floats
|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.
Add Makefile.in so that configure can determine if inet_aton.o is required
Add CFLAGS= @CPPFLAGS@ to Makefile.global and configure so that build is
useful for finding extra header files
Split header files from libraries in build. Doesn't make much sense to
look for a header file in /usr/local/lib, nor to look for a library
in /usr/local/include :)
Add a 'build' script. All it currently does is prompts the user for additional 'lib'
directories to search to find libraries, and then runs ./configure directly
Marc G. Fournier [Sun, 26 Jan 1997 17:28:48 +0000 (17:28 +0000)]
|From: Keith Parks <emkxp01@mtcc.demon.co.uk>
|Subject: [PATCH] adding SYS_TIME just for fun.
|
|Hi,
|
|Whilst I was playing round with the European dates patch I noticed the sysfunc()
|that allows you to do :-
|
|create table test ( da date);
|insert into test values (SYS_DATE);
|
|and have the current system date inserted.
|
|So I thought it would be nice to have the SYS_TIME facility too.
|
|I've cloned the function and changed a few things and there you have it,
|you can now do:
|
|create table test2 ( ti time);
|insert into test2 values (SYS_TIME);
Marc G. Fournier [Sat, 25 Jan 1997 23:54:08 +0000 (23:54 +0000)]
Remove rlstubs.[ch], since they weren't actually doing anything that couldn't
be #ifdef'd into psql.c itself
From what I can tell, if USE_READLINE is true or false, psql works under
FreeBSD, without configure. Now to test it *again* under sparc_solaris
with configure and see if it works...
Marc G. Fournier [Sat, 25 Jan 1997 21:58:08 +0000 (21:58 +0000)]
Modifications to handle the situation where readline.h exists, but
history.h doesn't...previously, it was assumed that both existed, or
didn't exist...but this assumption fails on the one sparc_solaris box
that I have access to, and could exist in other circumstances
Bruce Momjian [Sat, 25 Jan 1997 21:09:20 +0000 (21:09 +0000)]
would you mind committing the following changes for me? (the first
bug causes compilation to fail on alpha, the second causes a compiler
in this environment
projects / postgresql / log