result is not used anyway. This also fixes Vista's build problems.

WAL records that shows whether it is safe to remove full-page images
(ie, whether or not an on-line backup was in progress when the WAL entry
was made).  Also make provision for an XLOG_NOOP record type that can be
used to fill in the extra space when decompressing the data for restore.

This is the portion of Koichi Suzuki's "full page writes" patch that
has to go into the core database.  The remainder of that work is two
external compression and decompression programs, which for the time being
will undergo separate development on pgfoundry.  Per discussion.

Also, twiddle the handling of BTREE_SPLIT records to ensure it'll be
possible to compress them (the previous coding caused essential info
to be omitted).  The other commonly-used record types seem OK already,
with the possible exception of GIN and GIST WAL records, which I don't
understand well enough to opine on.

FreezeXid introduced in a recent commit, so there isn't any data loss in this
approach.

Doing it causes ALTER TABLE (or rather, the forms of it that cause a full table
rewrite) to be affected as well.  In this case, the frozen point is RecentXmin,
because after the rewrite all the tuples are relabeled with the rewriting
transaction's Xid.

TOAST tables are fixed automatically as well, as fallout of the way they were
already being handled in the respective code paths.

With this patch, there is no longer need to VACUUM tables for Xid wraparound
purposes that have been cleaned up via TRUNCATE or CLUSTER.

.SECONDARY target.  This makes experimentation with the PDF builds easier.

< * Fix problem with excessive logging during SSL disconnection
> * -Fix problem with excessive logging during SSL disconnection

had been taught not to do that ages ago, the SSL code was helpfully bleating
anyway.  Resolves some recent reports such as bug #3266; however the
underlying cause of the related bug #2829 is still unclear.

>
> * Support scoped IPv6 addresses
>
>   http://archives.postgresql.org/pgsql-bugs/2007-05/msg00111.php

and inet_server_addr() fail if the client connected over a "scoped" IPv6
address.  In this case getnameinfo() will return a string ending with
a poorly-standardized "%something" zone specifier, which these functions
try to feed to network_in(), which won't take it.  So that we don't lose
functionality altogether, suppress the zone specifier before giving the
string to network_in().  Per report from Brian Hirt.

TODO: probably someday the inet type should support scoped IPv6 addresses,
and then this patch should be reverted.

Backpatch to 8.2 ... is it worth going further?

* Implement the SQL standard mechanism whereby REVOKE ROLE revokes only
  the privilege granted by the invoking role, and not those granted
  by other roles
>
>   http://archives.postgresql.org/pgsql-bugs/2007-05/msg00010.php

>
> * Implement the SQL standard mechanism whereby REVOKE ROLE revokes only
>   the privilege granted by the invoking role, and not those granted
>   by other roles

>
> * Fix problem with excessive logging during SSL disconnection
>
>   http://archives.postgresql.org/pgsql-bugs/2006-12/msg00122.php
>   http://archives.postgresql.org/pgsql-bugs/2007-05/msg00065.php

        Moved page-level functions from pgstattuple to
contrib/pageinspect.

recompute the limit/offset immediately, so that the updated values are
available when the child's ReScan function is invoked.  Add a regression
test for this, too.  Bug is new in HEAD (due to the bounded-sorting patch)
so no need for back-patch.

I did not do anything about merging this signaling with chgParam processing,
but if we were to do that we'd still need to compute the updated values
at this point rather than during the first ProcNode call.

Per observation and test case from Greg Stark, though I didn't use his patch.

Simon and Heikki

to avoid losing useful Xid information in not-so-old tuples.  This makes
CLUSTER behave the same as VACUUM as far a tuple-freezing behavior goes
(though CLUSTER does not yet advance the table's relfrozenxid).

While at it, move the actual freezing operation in rewriteheap.c to a more
appropriate place, and document it thoroughly.  This part of the patch from
Tom Lane.

avoid a later needless VACUUM for Xid-wraparound purposes.  We can do this
since the table is known to be left empty, so no Xid remains on it.

Per discussion.

applied to live tuples older than a recent Xmin, not to tuples that may be part
of an update chain.  Those still keep their original markings.

This patch makes it possible for CLUSTER to advance relfrozenxid, thus avoiding
the need of vacuuming the table for Xid wraparound purposes.  That will be
patched separately.

Patch from Heikki Linnakangas.

when the grantor has been dropped.  This is a workaround for the fact
that we don't track the grantor as a shared dependency.

Workaround for when it is: include the ossp directory using --with-includes.

information" is un-good English.

parentheses in syntax descriptions. Consistently use the present tense
when describing the basic purpose of each "DROP" command. Add a few
more hyperlinks.

that require alignment.

Add a paragraph to the "User-Defined Types" chapter on using these
macros since it seems like they're a hit.

Gregory Stark

launcher daemon.

"autovacuum = off", the system may still periodically start autovacuum
processes to prevent XID wraparound. Patch from David Fetter, with
editorializing.

* Add support for SQL-standard GENERATED/IDENTITY columns

>   http://archives.postgresql.org/pgsql-hackers/2007-05/msg00344.php
>   http://archives.postgresql.org/pgsql-patches/2007-05/msg00076.php

there's an indirect dependency on the owner via the parent table.  We were
already handling indexes that way, but not toast tables for some reason.
Saves a little catalog space and cuts down the verbosity of checkSharedDependencies
reports.

patch; also make the code logic a bit more self-consistent.

ActiveSnapshot.  Having it affect ActiveSnapshot only in the unusual
case of needing to replan seems a bad idea, and there's also the problem
that the created snap might be in a relatively short-lived context, as
noted by Jan Wieck.  Also, there's no need to force a new snap at all
unless we are called with no snap currently set, which is an unusual
case in itself.

and only a truncated log of the objects in the current database to the client.
Also, instead of reporting object counts for all databases on which the user
might own objects, report only as many as fit in the predefined line count.

This is to avoid flooding the client when the user owns too many objects,
which could cause problems.

Per report from Ed L. on April 4th and subsequent discussion.

Per request from Andrew Dunstan.

< 	o Add support for arrays of complex types
>
> 	  http://archives.postgresql.org/pgsql-patches/2007-05/msg00114.php
>
> 	o -Add support for arrays of complex types