< 	o Consider reducing on-disk varlena length from four to two
< 	  because a heap row cannot be more than 64k in length
> 	o Consider reducing on-disk varlena length from four bytes to
> 	  two because a heap row cannot be more than 64k in length

ITAGAKI Takahiro

If this breaks things due to missing libxslt, then I'll have to
revert it, but let's see if it breaks the buildfarm.

Workarounds in case libxslt is missing include:
. don't configure with libxml, or
. don't build contrib modules from the contrib Makefile (use the individual module Makefiles instead), or
. change the xml2 Makefile

ITAGAKI Takahiro

EXPLAIN ANALYZE can sometimes be significantly slower than running
the same query normally, and make some minor markup improvements.

ref page (sorry, my fault!), and simplify the coding of
ResetTempTableNamespace().

> * -Add RESET SESSION command to reset all session state

fast flow of new fsync requests can prevent mdsync() from ever completing.
This was an unforeseen consequence of a patch added in Mar 2006 to prevent
the fsync request queue from overflowing.  Problem identified by Heikki
Linnakangas and independently by ITAGAKI Takahiro; fix based on ideas from
Takahiro-san, Heikki, and Tom.

Back-patch as far as 8.1 because a previous back-patch introduced the problem
into 8.1 ...

report from David Darville.  Back-patch as far as 8.1, which may or may not
have the problem but it seems a safe change anyway.

reviewed by Neil Conway. This patch adds the following DDL command
variants: RESET SESSION, RESET TEMP, RESET PLANS, CLOSE ALL, and
DEALLOCATE ALL. RESET SESSION is intended for use by connection
pool software and the like, in order to reset a client session
to something close to its initial state.

Note that while most of these command variants can be executed
inside a transaction block (but are not transaction-aware!),
RESET SESSION cannot. While this is inconsistent, it is intended
to catch programmer mistakes: RESET SESSION in an open transaction
block is probably unintended.

< 	o Allow single-byte header storage for arrays
> 	o Allow single-byte header storage for array elements

(original code *always* created a full-page image for the left page, thus
leaving the intended savings unrealized), avoid risk of not having enough room
on the page during xlog restore, squeeze out another couple bytes in the xlog
record, clean up neglected comments.

> 	o Allow single-byte header storage for arrays

> 	o Have WITH CONSTRAINTS also create constraint indexes
> 	  http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php

index types can be reliably distinguished by examining the special space
on an index page.  Per my earlier proposal, plus the realization that
there's no need for btree's vacuum cycle ID to cycle through every possible
16-bit value.  Restricting its range a little costs nearly nothing and
eliminates the possibility of collisions.
Memo to self: remember to make bitmap indexes play along with this scheme,
assuming that patch ever gets accepted.

* Simplify ability to create partitioned tables
>   http://archives.postgresql.org/pgsql-hackers/2007-04/msg00151.php

and vacuumdb.
ITAGAKI Takahiro, with minor fixes from me.

> 	o -Make CLUSTER preserve recently-dead tuples per MVCC requirements

Patch contributed by Pavan Deolasee. Along with Japanese doc
modification by Tatsuo Ishii.

> 	o -Add more logical syntax CLUSTER table USING index;

Holger Schurig

contrib/pgbuffercache.

Greg Smith

confusion.

Michael Fuhr

> * -Allow use of indexes to search for NULLs

        o -Support a smaller header for short variable-length fields

there are some corner cases where this is needed by ruleutils.c for
proper display of variables during EXPLAIN.

Teodor Sigaev, with some kibitzing from Tom Lane.

types.

Smith. Along with Japanese doc updation by Tasuo Ishii.

> This patch changes the way pgbench outputs its latency log files so that
> every transaction gets a timestamp and notes which transaction type was
> executed.  It's a one-line change that just dumps some additional
> information that was already sitting in that area of code. I also made a
> couple of documentation corrections and clarifications on some of the more
> confusing features of pgbench.
>
> It's straightforward to parse log files in this format to analyze what
> happened during the test at a higher level than was possible with the
> original format.  You can find some rough sample code to convert this
> latency format into CVS files and then into graphs at
> http://www.westnet.com/~gsmith/content/postgresql/pgbench.htm which I'll
> be expanding on once I get all my little patches sent in here.