* Speed WAL recovery by allowing more than one page to be prefetched

  This involves having a separate process that can be told which pages
  the recovery process will need in the near future.

>   http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php
>   http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php
<

during a bitmap index scan.  This cannot affect the query results
(since we're just dumping the TIDs into a bitmap) but it might offer
some advantage in locality of access to the index.  Per Greg Stark.

> 	o Recreate pg_xlog/archive_status/ if it doesn't exist after
> 	  restoring from a PITR backup
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-12/msg00487.php

value for a precision is negative, act as though precision weren't
specified at all, that is the whole .* part of the format spec should
be ignored.  Our previous coding took it as .0 which is certainly
wrong.  Per report from Kris Jurka and local testing.

Possibly this should be back-patched, but it would be good to get
some more testing first; in any case there are no known cases where
there's really a problem on the backend side.

>
> * Consider Cartesian joins when both relations are needed to form an
>   indexscan qualification for a third relation
>
>   http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php

        o Allow COPY to report error lines and continue

          This requires the use of a savepoint before each COPY line is
          processed, with ROLLBACK on COPY failure.
> 	  http://archives.postgresql.org/pgsql-hackers/2007-12/msg00572.php

>
> * Allow SSL key file permission checks to be optionally disabled when
>   sharing SSL keys with other applications
>
>   http://archives.postgresql.org/pgsql-bugs/2007-12/msg00069.php

>
> * Reduce BIT data type overhead using short varlena headers
>
>   http://archives.postgresql.org/pgsql-general/2007-12/msg00273.php

> * Reduce file system activity overhead of statistics file pgstat.stat
>
>   http://archives.postgresql.org/pgsql-general/2007-12/msg00106.php
>

> * Consider if CommandCounterIncrement() can avoid its
>   AcceptInvalidationMessages() call
>
>   http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php

* Add SQL:2003 WITH RECURSIVE (hierarchical) queries to SELECT

>   http://archives.postgresql.org/pgsql-hackers/2007-11/msg01334.php

>
> 	o Remove pre-7.3 pg_dump code that assumes pg_depend does not exit

* Improve text search error messages

>   http://archives.postgresql.org/pgsql-hackers/2007-11/msg01146.php

> * Improve text search error messages
>
>   http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php
>
>
> * Fix /contrib/ltree operator
>
>   http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php

>
> 	o Fix server restart problem when the server was shutdown during
> 	  a PITR backup
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-11/msg00800.php
>

* Consider increasing the number of default statistics target, and
  reduce statistics target overhead

>   http://archives.postgresql.org/pgsql-hackers/2008-01/msg01066.php

support DTrace in the future.

Switch from using DTRACE_PROBEn macros to the dynamically generated macros.
Use "dtrace -h" to create a header file that contains the dynamically
generated macros to be used in the source code instead of the DTRACE_PROBEn
macros.  A dummy header file is generated for builds without DTrace support.

Author: Robert Lor <Robert.Lor@sun.com>

changed in case a new file got added.

>
> 	o Allow Kerberos to disable stripping of realms so we can
> 	  check the username@realm against multiple realms
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-11/msg00009.php

While at it, rename option lookup functions to make names clearer, per
discussion with Tom.

make_greater_string needs the < procedure not the >= one.  Spotted by
Peter.

needed anywhere after my previous patch.  Noticed by Tom Lane.

Also, remove #include <signal.h> from sinval.c.

oprofile shows that a nontrivial amount of time is being spent in
repeated calls to index_getprocinfo, which really only needs to be
called once.  So do that, and inline _hash_datum2hashkey to make it
work.

linear search when checking child-transaction XIDs.  This makes for an
important speedup in transactions that have large numbers of children,
as in a recent example from Craig Ringer.  We can also get rid of an
ugly kluge that represented lists of TransactionIds as lists of OIDs.

Heikki Linnakangas

> 	o -During index creation, pre-sort the tuples to improve build speed

maintenance_work_mem and effective_cache_size on index creation speed.

bucket number, so as to ensure locality of access to the index during the
insertion step.  Without this, building an index significantly larger than
available RAM takes a very long time because of thrashing.  On the other
hand, sorting is just useless overhead when the index does fit in RAM.
We choose to sort when the initial index size exceeds effective_cache_size.

This is a revised version of work by Tom Raney and Shreya Bhargava.

deals with the queue, including locking etc, is all in sinvaladt.c.  This means
that the struct definition of the queue, and the queue pointer, are now
internal "implementation details" inside sinvaladt.c.

Per my proposal dated 25-Jun-2007 and followup discussion.

two buckets at the start, we create a number of buckets appropriate for the
estimated size of the table.  This avoids a lot of expensive bucket-split
actions during initial index build on an already-populated table.

This is one of the two core ideas of Tom Raney and Shreya Bhargava's patch
to reduce hash index build time.  I'm committing it separately to make it
easier for people to test the effects of this separately from the effects
of their other core idea (pre-sorting the index entries by bucket number).

This accidentally failed to fail before 8.3, because the context we were
switching back to was long-lived anyway; but it sure looks risky as can be
now.  Well spotted by Pavan Deolasee.

job (i.e. to prevent Xid wraparound problems.)  Bug reported by ITAGAKI
Takahiro in 20080314103837.63D3.52131E4D@oss.ntt.co.jp, though I didn't use his
patch.

that are reported as "equal" by wcscoll() are checked to see if they really
are bitwise equal, and are sorted per strcmp() if not.  We made this happen
a couple of years ago in the regular code path, but it unaccountably got
left out of the Windows/UTF8 case (probably brain fade on my part at the
time).  As in the prior set of changes, affected users may need to reindex
indexes on textual columns.

Backpatch as far as 8.2, which is the oldest release we are still supporting
on Windows.

messages if the calling transaction aborts later on.  Collapsing out line
pointer redirects is a done deal as soon as we complete the page update,
so syscache *must* be notified even if the VACUUM FULL as a whole doesn't
complete.  To fix, add some functionality to inval.c to allow the pending
inval messages to be sent immediately while heap_page_prune is still
running.  The implementation is a bit chintzy: it will only work in the
context of VACUUM FULL.  But that's all we need now, and it can always be
extended later if needed.  Per my trouble report of a week ago.

* Do async I/O for faster random read-ahead of data

  Async I/O allows multiple I/O requests to be sent to the disk with
  results coming back asynchronously.

>   http://archives.postgresql.org/pgsql-performance/2007-09/msg00255.php

(probably NULL) before exiting.  Up to now it's just left the variable as it
set it, which means that after we're done processing the current client
message, ActiveSnapshot is probably pointing at garbage (because this function
is typically run in MessageContext which will get reset).  There doesn't seem
to have been any code path in which that mattered before 8.3, but now the
plancache module might try to use the stale value if the next client message
is a Bind for a prepared statement that is in need of replanning.  Per report
from Alex Hunsaker.