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.

< * Include the symbolic SQLSTATE name in verbose error reports
<
<   http://archives.postgresql.org/pgsql-general/2007-09/msg00438.php

> * Expire published xmin for read-only and idle transactions
>
>   http://archives.postgresql.org/pgsql-hackers/2007-09/msg00343.php

pg_listener modifications commanded by LISTEN and UNLISTEN until the end
of the current transaction.  This allows us to hold the ExclusiveLock on
pg_listener until after commit, with no greater risk of deadlock than there
was before.  Aside from fixing the race condition, this gets rid of a
truly ugly kludge that was there before, namely having to ignore
HeapTupleBeingUpdated failures during NOTIFY.  There is a small potential
incompatibility, which is that if a transaction issues LISTEN or UNLISTEN
and then looks into pg_listener before committing, it won't see any resulting
row insertion or deletion, where before it would have.  It seems unlikely
that anyone would be depending on that, though.

This patch also disallows LISTEN and UNLISTEN inside a prepared transaction.
That case had some pretty undesirable properties already, such as possibly
allowing pg_listener entries to be made for PIDs no longer present, so
disallowing it seems like a better idea than trying to maintain the behavior.

>
> * Consider a special data type for regular expressions
>
>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php

* Add array_accum() and array_to_set() functions for arrays

  The standards specify array_agg() and UNNEST.
  http://archives.postgresql.org/pgsql-hackers/2007-08/msg00464.php

* Consider a simplified API for full text searches

>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php

>
> 	o Convert MSVC build system to remove most batch files
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-08/msg00961.php

* Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY

>   http://archives.postgresql.org/pgsql-performance/2007-08/msg00289.php

> 	o Diagnose problem where shared memory can sometimes not be
> 	  attached by postmaster children
>
> 	  http://archives.postgresql.org/pgsql-general/2007-08/msg01377.php
>

>
> * Remove use of MAKE_PTR and MAKE_OFFSET macros
>
>   http://archives.postgresql.org/pgsql-general/2007-08/msg01510.php

>
> * Add array_accum() and array_to_set() functions for arrays
>
>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00464.php

comply with TPC-B.  Per Itagaki Takahiro and discussion of bug#3681.

* Improve speed with indexes

  For large table adjustments during VACUUM FULL, it is faster to cluster
  or reindex rather than update the index.  Also, index updates can bloat
  the index.


>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00307.php

>
> * Allow domains to be cast
>
>   http://archives.postgresql.org/pgsql-hackers/2003-06/msg01206.php
>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00289.php

>
> * Consider simplifying how memory context resets handle child contexts
>
>   http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php

>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php

* Consider increasing NUM_CLOG_BUFFERS

>   http://archives.postgresql.org/pgsql-performance/2007-08/msg00024.php

* Consider increasing NUM_CLOG_BUFFERS
>
>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00030.php
>

	test=> \copy billing_data from ../BillingSamplePricerFile.csv with csv
	   header quote as '"' null as 'abc' null as '123'
	\copy: parse error at "null"

Per report from Stephen Frost

        o Allow COPY in CSV mode to control whether a quoted zero-length
          string is treated as NULL

          Currently this is always treated as a zero-length string,
          which generates an error when loading into an integer column

>
> 	o Allow COPY in CSV mode to control whether "" is treated as NULL
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php

>
> 	o Improve logic of determining if an identifier is a a
> 	  variable or column name
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-07/msg00436.php

>
> * Add automated check for invalid C++ source code constructs
>
>   http://archives.postgresql.org/pgsql-patches/2007-07/msg00056.php

> * Research use of signals and sleep wake ups
>
>   http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php

* 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