are both used.

Albe Laurenz

* Reduce checkpoint performance degredation by forcing data to disk
  more evenly

>   http://archives.postgresql.org/pgsql-patches/2006-12/msg00104.php

* Allow sequential scans to take advantage of other concurrent
  sequential scans, also called "Synchronised Scanning"
>
>   http://archives.postgresql.org/pgsql-hackers/2006-12/msg00784.php

> * Reduce checkpoint performance degredation by forcing data to disk
>   more evenly
>
>   http://archives.postgresql.org/pgsql-hackers/2006-12/msg00337.php
>   http://archives.postgresql.org/pgsql-hackers/2007-01/msg00079.php

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

generated solution files for what to install, instead of blindly copying
everything as it previously did. With the previous quick-n-dirty
version, it would copy old DLLs if you reconfigured in a way that didn't
include subprojects like a PL for example.

Magnus Hagander.

Windows. Per Magnus Hagander, this is not recommended.

> 	o Allow column display reordering by recording a display,
> 	  storage, and permanent id for every column?
>
> 	  http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php
>

Security: CVE-2007-0555, CVE-2007-0556

made query plan.  Use of ALTER COLUMN TYPE creates a hazard for cached
query plans: they could contain Vars that claim a column has a different
type than it now has.  Fix this by checking during plan startup that Vars
at relation scan level match the current relation tuple descriptor.  Since
at that point we already have at least AccessShareLock, we can be sure the
column type will not change underneath us later in the query.  However,
since a backend's locks do not conflict against itself, there is still a
hole for an attacker to exploit: he could try to execute ALTER COLUMN TYPE
while a query is in progress in the current backend.  Seal that hole by
rejecting ALTER TABLE whenever the target relation is already open in
the current backend.

This is a significant security hole: not only can one trivially crash the
backend, but with appropriate misuse of pass-by-reference datatypes it is
possible to read out arbitrary locations in the server process's memory,
which could allow retrieving database content the user should not be able
to see.  Our thanks to Jeff Trout for the initial report.

Security: CVE-2007-0556

we should check that the function code returns the claimed result datatype
every time we parse the function for execution.  Formerly, for simple
scalar result types we assumed the creation-time check was sufficient, but
this fails if the function selects from a table that's been redefined since
then, and even more obviously fails if check_function_bodies had been OFF.

This is a significant security hole: not only can one trivially crash the
backend, but with appropriate misuse of pass-by-reference datatypes it is
possible to read out arbitrary locations in the server process's memory,
which could allow retrieving database content the user should not be able
to see.  Our thanks to Jeff Trout for the initial report.

Security: CVE-2007-0555

"can't" -> "cannot" section.

for the recent may/might cleanup.

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.