shared hardware section, and mention DRBD as a popular solution.

recent may/might cleanup, in the hopes that this will unbreak the
buildfarm. Per report from Stefan Kaltenbrunner.

an error will be thrown correctly if the variable is of a NOT NULL domain.
Report and almost-correct fix from Sergiy Vyshnevetskiy (bug #2948).

        o Add long file support for binary pg_dump output
>
> 	  http://archives.postgresql.org/pgsql-hackers/2006-12/msg00551.php

Standard English uses "may", "can", and "might" in different ways:

        may - permission, "You may borrow my rake."

        can - ability, "I can lift that log."

        might - possibility, "It might rain today."

Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice.  Similarly, "It may crash" is better stated, "It might crash".

behavior has changed.

Daojing.Zhou

<   http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php
>   http://archives.postgresql.org/pgsql-hackers/2006-12/msg00568.php
>

>
> * Tighten function permission checks
>
>   http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php
>

>
> * Tighten trigger permission checks
>
>   http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php
>

and --password for pg_dump, pg_dumpall and pg_restore, per complaint by
Michael Schmidt. Patch from Magnus Hagander.

>
> * 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/2006-11/msg01011.php
>   http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php

created and increments.  The old docs created the sequence, then showed
a nextval() of 114.

      o Fix RENAME to work on variables other than OLD/NEW
>       http://archives.postgresql.org/pgsql-hackers/2007-01/msg01615.php

appropriate.

Standard English uses "may", "can", and "might" in different ways:

        may - permission, "You may borrow my rake."

        can - ability, "I can lift that log."

        might - possibility, "It might rain today."

Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice.  Similarly, "It may crash" is better stated, "It might crash".

Standard English uses "may", "can", and "might" in different ways:

        may - permission, "You may borrow my rake."

        can - ability, "I can lift that log."

        might - possibility, "It might rain today."

Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice.  Similarly, "It may crash" is better stated, "It might crash".

Also update two error messages mentioned in the documenation to match.

targets, and refactor the tablespace setup code into a separate
Makefile target.

nonportable "hh" sprintf(3) length modifier. Instead, do the parsing
and output by hand. The code to do this isn't ideal, but this is
an interim measure anyway: the uuid type should probably use the
in-memory struct layout specified by RFC 4122. For now, this patch
should hopefully rectify the buildfarm failures for the uuid test.

Along the way, re-add pg_cast entries for uuid <-> varchar, which
I mistakenly removed earlier, and bump the catversion.

or other share-directory files are inaccessible for some reason other
than not existing.  Inspired by trouble report from Simon Kinsella.

In this case extractQuery should returns -1 as nentries. This changes
prototype of extractQuery method to use int32* instead of uint32* for
nentries argument.
Based on that gincostestimate may see two corner cases: nothing will be found
or seqscan should be used.

Per proposal at http://archives.postgresql.org/pgsql-hackers/2007-01/msg01581.php

PS tsearch_core patch should be sightly modified to support changes, but I'm
waiting a verdict about reviewing of tsearch_core patch.

      o Fix RENAME to work on variables other than OLD/NEW
>
> 		  http://archives.postgresql.org/pgsql-hackers/2002-03/msg00591.php
>

>
> * Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY
>
>   This is difficult because you must upgrade to an exclusive table lock
>   to replace the existing index file.  CREATE INDEX CONCURRENTLY does not
>   have this complication.  This would allow index compaction without
>   downtime.

<   reindex rather than update the index.
>   reindex rather than update the index.  Also, index updates can
>   bloat the index.

> 	o ARRAY[[1,2],[3,4]])[1] should return the same values as
> 	  ARRAY[[1,2],[3,4]])[1:1];
>

more, and standard_conforming_strings less, because in the future non-E
strings will not treat backslashes specially.

Also use E'' strings where backslashes are used in examples. (The
existing examples would have drawn warnings.)

Backpatch to 8.2.X.

The original coding failed (tried to access deallocated memory) if there were
two active call sites (fn_extra pointers) for the same function and the
function definition was updated.  Also, if an update of a recursive function
was detected upon nested entry to the function, the existing compiled version
was summarily deallocated, resulting in crash upon return to the outer
instance.  Problem observed while studying a bug report from Sergiy
Vyshnevetskiy.

Bug does not exist before 8.1 since older versions just leaked the memory of
obsoleted compiled functions, rather than trying to reclaim it.

by plpgsql can themselves use SPI --- possibly indirectly, as in the case
of domain_in() invoking plpgsql functions in a domain check constraint.
Per bug #2945 from Sergiy Vyshnevetskiy.

Somewhat arbitrarily, I've chosen to back-patch this as far as 8.0.  Given
the lack of prior complaints, it doesn't seem critical for 7.x.

Hashing for aggregation purposes still needs work, so it's not time to
mark any cross-type operators as hashable for general use, but these cases
work if the operators are so marked by hand in the system catalogs.