rightmost on its tree level, we split 2/3 to the left and 1/3 to the
new right page, rather than the even split we use elsewhere.  The idea
is that when faced with a steadily increasing series of inserted keys
(such as sequence or timestamp values), we'll end up with a btree that's
about 2/3ds full not 1/2 full, which is much closer to the desired
steady-state load for a btree.  Per suggestion from Ann Harrison of
IBPhoenix.

	* HOLDER/HOLDERTAB rename to PROCLOCK/PROCLOCKTAG (Tom)

Didn't use PROCLOCKLINK because it made PROCLOCKLINKTAG too long.

pointers to data that will be changed by any later call to setlocale.
Must copy what they return to be sure we get the right answer.
Karel Zak, further tweaks by Tom Lane.

returns a string corresponding to the new setting, not the old,
therefore the previous patch was quite wrong.

SInvalLock.  GetSnapshotData(true) has to use exclusive lock, since
it sets MyProc->xmin.

per tuple memory context doesn't discard them.

Still need an update for horology-solaris-1947.out ...

existing lock manager and spinlocks: it understands exclusive vs shared
lock but has few other fancy features.  Replace most uses of spinlocks
with lightweight locks.  All remaining uses of spinlocks have very short
lock hold times (a few dozen instructions), so tweak spinlock backoff
code to work efficiently given this assumption.  All per my proposal on
pghackers 26-Sep-01.

two performance improvements.  I put an explanation of the
changes at

http://cs1.cs.nyu.edu/been/postgres-rtree.html

The performance improvements are quite significant.

All the changes are in the file src/backend/access/rtree/rtree.c

I was working with the 7.1.3 code.

I'm including the diff output as an attachment.

Kenneth Been

Marko Kreen

Converted pgcrypto one too.

* Changed default randomness source to libc random()
  That way pgcrypto does not have any external dependencies
  and should work everywhere.
* Re-enabled pgcrypto build in contrib/makefile
* contrib/README update - there is more stuff than
  only 'hash functions'
* Noted the libc random fact in README.pgcrypto


Marko Kreen

Liam Stewart

pg_ctl.sh which were unquoted when inside of [].

Justin Clift

DatabaseMetaData.getColumn(). I proposed a patch that would change the
number of queries to find out all columns in a table from 2 * N + 1 to 1 (N
being the number of columns reported) by using some outer joins. I also
fixed the fact that getColumns() only returned columns that had a default
defined. OTOH, I did not use to change the code required for obtaining a
column's remarks (by using col_description() for 7.2  and requested by Tom
Lane).

Finally, I have found a way to get all the column details in a single query
*and* use col_description() for 7.2 servers. A patch is attached. It
overrules Ren? Pijlman's fix for this that was committed just today, but
still used N + 1 queries (sorry Ren? ;-) )

I also fixed the return values for TABLE_CAT and TABLE_SCHEM from "" to
null, to be more standard compliant (and requested in Ren?'s mail found at
http://fts.postgresql.org/db/mw/msg.html?mid=1034253).

As always, the JDBC1 version has not been tested as I have no JDK 1.1

Jeroen van Vianen

Kristis Markis.

 need more work, but at least they have something now.

Start chapter on recovery techniques. Still needs work for release.

Define a new function, GetCurrentTransactionStartTimeUsec() to get the time
 to this precision.
Allow now() and timestamp 'now' to use this higher precision result so
 we now have fractional seconds in this "constant".
Add timestamp without time zone type.
Move previous timestamp type to timestamp with time zone.
Accept another ISO variant for date/time values: yyyy-mm-ddThh:mm:ss
 (note the "T" separating the day from hours information).
Remove 'current' from date/time types; convert to 'now' in input.
Separate time and timetz regression tests.
Separate timestamp and timestamptz regression test.

Modify the timestamp test to reflect the "no time zone" behavior of this
 new code; timestamptz resembles the old timestamp code.

more reasonable location for them.

proposal of 26-Aug.

Per gripe 9/26.

check *can* return HEAPTUPLE_INSERT_IN_PROGRESS or HEAPTUPLE_DELETE_IN_PROGRESS,
even though we have ShareLock on the relation.  To wit, this can happen
if the tuple was inserted/deleted by our own transaction.  Per report from
Justin Clift 9/23.

need this, and it will create a Y2038 failure.  Per report from David
Wheeler, who is evidently running on a platform where time_t is already
negative.