* Test to see if calling PreallocXlogFiles() from the background writer
  will help with WAL segment creation latency

  http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php

> * Consider adding buffers the background writer finds reusable to the
>   free list
>
> * Consider wither increasing BM_MAX_USAGE_COUNT improves performance
>
>   http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php

* Reduce storage space for small NUMERICs

>   http://archives.postgresql.org/pgsql-hackers/2007-06/msg00715.php

before it goes groveling through the ProcArray.  In situations where the same
recently-committed transaction ID is checked repeatedly by tqual.c, this saves
a lot of shared-memory searches.  And it's cheap enough that it shouldn't
hurt noticeably when it doesn't help.
Concept and patch by Simon, some minor tweaking and comment-cleanup by Tom.

> 	o Consider normalizing fractions in postgresql.conf, perhaps
> 	  using '%'
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php

> * Consider sorting writes during checkpoint
>
>   http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php

>
> * Prefix command-line utilities like createuser with 'pg_'
>
>   http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php

>
> * Change memory allocation for multi-byte functions so memory is
>   allocated inside conversion functions
>
>   Currently we preallocate memory based on worst-case usage.

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

  Also consider having a larger statistics target for indexed columns
  and expression indexes
<
>   http://archives.postgresql.org/pgsql-general/2007-06/msg00542.php

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

  Also consider having a larger statistics target for indexed columns
  and expression indexes
>   http://archives.postgresql.org/pgsql-general/2007-05/msg01228.php
>

>
> * Consider increasing the number of default statistics target, and
>   reduce statistics target overhead
>
>   Also consider having a larger statistics target for indexed columns
>   and expression indexes

>
> * Consider using a hash for joining to a large IN (VALUES ...) list
>
>   http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php

>
> * Consider a more compact data representation for dead tuples
>
>   http://archives.postgresql.org/pgsql-patches/2007-05/msg00143.php

* Fix problem when multiple subtransactions of the same outer transaction
  hold different types of locks, and one subtransaction aborts

>   http://archives.postgresql.org/pgsql-hackers/2007-05/msg00773.php

>
> * Add temporal versions of generate_series()
>
>   http://archives.postgresql.org/pgsql-hackers/2007-04/msg01180.php

o Review handling of MOVE and FETCH


http://archives.postgresql.org/pgsql-patches/2007-04/msg00527.php

> 	o Prevent pg_dump/pg_restore from being affected by
> 	  statement_timeout
>
> 	  Using psql to restore a pg_dump dump is also affected.

+         Setting <varname>statement_timeout</> in
+         <filename>postgresql.conf</> is not recommended because it
+         affects all sessions.

Backpatch to 8.3.X.

> * Allow statistics last vacuum/analyze execution times to be displayed
>   without requiring stats_row_level to be enabled

<
< 	o Set up autovacuum to ignore statement_timeout set in
< 	  postgresql.conf
<
< 	  http://archives.postgresql.org/pgsql-hackers/2007-03/msg01753.php

>
> * Consider adding buffers the BGW finds reusable to the free list
>
>   http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php
>
> * Automatically tune bgwriter_delay based on activity rather then using a
>   fixed interval
>
>   http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php

because it affects all sessions, including autovacuum.

>
> 	o Set up autovacuum to ignore statement_timeout set in
> 	  postgresql.conf
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-03/msg01753.php

* Optimize referential integrity checks

>   http://archives.postgresql.org/pgsql-hackers/2007-04/msg00744.php

* Allow administrators to safely terminate individual sessions either
  via an SQL function or SIGTERM

>   http://archives.postgresql.org/pgsql-hackers/2007-04/msg00218.php

This prevents compiler optimizations that assume overflow won't occur, which
breaks numerous overflow tests that we need to have working.  It is known
that gcc 4.3 causes problems and possible that 4.1 does.  Per my proposal
of some time ago and a recent report from Kris Jurka.

Backpatch as far as 8.0, which is as far as the patch conveniently goes.
7.x was pretty short of overflow tests anyway, so it may not matter there,
even assuming that anyone cares whether 7.x builds on recent gcc.

than dividing them into 1GB segments as has been our longtime practice.  This
requires working support for large files in the operating system; at least for
the time being, it won't be the default.

Zdenek Kotala

>
> * Consider increasing the minimum allowed number of shared buffers
>
>   http://archives.postgresql.org/pgsql-bugs/2008-02/msg00157.php
>

variables to it. More need to be converted, but I wanted to get this in
before it conflicts with too much...

Other than just centralising the text-to-int conversion for parameters,
this allows the pg_settings view to contain a list of available options
and allows an error hint to show what values are allowed.

-1 to 1, not 0 to 1.  The actual behavior for values within this range
does not change.  Kris Jurka

treating them as zero.  Simon Riggs

NOTICE-grade messages are not logged by default.  Per pgsql-hackers
discussion back on 21-Nov-2007.

Simon Riggs

Itagaki Takahiro

FSMPageData (6 bytes) instead of PageFreeSpaceInfo (8 or 16 bytes)
for the temporary array of page-free-space information.

Itagaki Takahiro

the same chance of being selected as do numbers between them.  Problem
noted by Greg Stark; fix by Alexey Klyukin.

With the addition of multiple autovacuum workers, our choices were to delete
the check, document the interaction with autovacuum_max_workers, or complicate
the check to try to hide that interaction.  Since this restriction has never
been adequate to ensure backends can't run out of pinnable buffers, it doesn't
really have enough excuse to live to justify the second or third choices.
Per discussion of a complaint from Andreas Kling (see also bug #3888).

This commit also removes several documentation references to this restriction,
but I'm not sure I got them all.