> * -Compress WAL entries [wal]

> * -Change WAL to use 32-bit CRC, for performance reasons

to just around the bare recv() call that gets a command from the client.
The former placement in PostgresMain was unsafe because the intermediate
processing layers (especially SSL) use facilities such as malloc that are
not necessarily re-entrant.  Per report from counterstorm.com.

broke it.  Maybe we do need an automated check ...

- Added patch by Gavin Scott <gavin@planetacetech.com> for Intel 64bit hardware.

Instead of a separate CRC on each backup block, include backup blocks
in their parent WAL record's CRC; this is important to ensure that the
backup block really goes with the WAL record, ie there was not a page
tear right at the start of the backup block.  Implement a simple form
of compression of backup blocks: drop any run of zeroes starting at
pd_lower, so as not to store the unused 'hole' that commonly exists in
PG heap and index pages.  Tweak PageRepairFragmentation and related
routines to ensure they keep the unused space zeroed, so that the above
compression method remains effective.  All per recent discussions.

< 	o Allow COPY to understand \x as a hex byte
> 	o -Allow COPY to understand \x as a hex byte

supported.  This follows the C standard escapes.

Sergey Ten

and DDL statements.

Backpatch fix to 8.0.X.

Per report from Murthy Kambhampaty

expressions it constructed, causing scalarineqsel to become confused
if the underlying variable was of a domain type.  Per report from
Kevin Grittner.

WAL record; this is necessary to be sure we recognize stale WAL records
when a WAL page was only partially written during a system crash.

Robert Treat

that the parser now can, so that it can reverse-list cases involving
FieldSelect from a RECORD Var.

it can handle cases like (foo.x).y where foo is a subquery and x is
a function-returning-RECORD RTE in that subquery.

for efficiency's sake.  Mark Kirkwood.

and RelationNameGetTupleDesc() as deprecated; remove uses of the
latter in the contrib library.  Along the way, clean up crosstab()
code and documentation a little.

< * Prevent child tables from altering constraints like CHECK that were
<   inherited from the parent table
470a469,471
>
> 	o Prevent child tables from altering constraints like CHECK that were
> 	  inherited from the parent table

> * Prevent child tables from altering constraints like CHECK that were
>   inherited from the parent table

physical-tlist optimization can be applied to FunctionScan nodes as well
as regular tables and SubqueryScans.

hex/decimal/octal.  Documentation already updated.

BACKWARD COMPATIBLE CHANGE

conventions of only allowing octal, like \045.  Remove support for
\decimal, \0octal, and \0xhex which matches the strtol() function but
didn't make sense with backslashes.

These now return the same character:

	test=> \set x '\54'
	test=> \echo :x
	,
	test=> \set x '\054'
	test=> \echo :x
	,

THIS IS A BACKWARD COMPATIBILITY CHANGE.

key, compare the new and old row versions. If the foreign key column has
not changed, we needn't enqueue the trigger, since the update cannot
violate the foreign key. This optimization was previously applied in the
RI trigger function, but it is more efficient to avoid firing the trigger
altogether. Per recent discussion on pgsql-hackers.

Also add a regression test for some unintuitive foreign key behavior, and
refactor some code that deals with the OIDs of the various RI trigger
functions.

keys, rather than a single trigger for both events. This should not change
functionality, but it is more consistent: previously, there were trigger
functions for both "check_insert" and "check_update", but the former was
used for both events.

Bump catalog version number (not strictly necessary, but best to be
cautious).

a FOR UPDATE clause, if one is present.

cstring, rather than text, so as to eliminate useless conversions
inside the parser.  Per recent discussion.

would be evaluated only once anyway (ie, it's just a SELECT with no
FROM or an INSERT ... VALUES).  The planner can't do it any faster than
the executor, so no point in an extra copying of the expression tree.

pg_class_aclmask().  We only need to do this when we have to check
pg_shadow.usecatupd, and that's not relevant unless the target table
is a system catalog.  So we can usually avoid one syscache lookup.

are now reported via elog, eliminating the need to test the result code
at most call sites.  Make it possible for the caller to distinguish a
freshly acquired lock from one already held in the current transaction.
Use that capability to avoid redundant AcceptInvalidationMessages() calls
in LockRelation().

status of the most recently queried userid.  Since the common pattern is
many successive queries about the same user (ie, the current user) this
can save a lot of syscache probes.

which is a common case.

of a query.