unary minus operators.  We weren't attempting to prevent minus zero anywhere
else; in view of our gradual trend to make the float datatypes more IEEE
standard compliant, we should allow minus zero here rather than disallow it
elsewhere.

We don't, however, expect that all platforms will produce minus zero, so
we need to adjust the one affected regression test to allow both results.

Per discussion of bug #4660.

(In passing, clean up a couple other minor infelicities in float.c.)

its usual buffer cleaning duties during archive recovery, and it's responsible
for performing restartpoints.

This requires some changes in postmaster. When the startup process has done
all the initialization and is ready to start WAL redo, it signals the
postmaster to launch the background writer. The postmaster is signaled again
when the point in recovery is reached where we know that the database is in
consistent state. Postmaster isn't interested in that at the moment, but
that's the point where we could let other backends in to perform read-only
queries. The postmaster is signaled third time when the recovery has ended,
so that postmaster knows that it's safe to start accepting connections.

The startup process now traps SIGTERM, and performs a "clean" shutdown. If
you do a fast shutdown during recovery, a shutdown restartpoint is performed,
like a shutdown checkpoint, and postmaster kills the processes cleanly. You
still have to continue the recovery at next startup, though.

Currently, the background writer is only launched during archive recovery.
We could launch it during crash recovery as well, but it seems better to keep
that codepath as simple as possible, for the sake of robustness. And it
couldn't do any restartpoints during crash recovery anyway, so it wouldn't be
that useful.

log_restartpoints is gone. Use log_checkpoints instead. This is yet to be
documented.

This whole operation is a pre-requisite for Hot Standby, but has some value of
its own whether the hot standby patch makes 8.4 or not.

Simon Riggs, with lots of modifications by me.

and databases.

utilities.

The new code allows transfer of dropped column information to the
upgraded server.

translated somehow.

marking up each instance separately.

text domain, instead of the postgres one (or whatever the default may be).

unique for a particular query, if the index predicate is satisfied.  This
requires a bit of reordering of operations so that we check the predicates
before doing any selectivity estimates, but shouldn't really cause any
noticeable slowdown.  Per a comment from Michal Politowski.

since it can be transient failures, causing kill() to not
properly send signals.

Original patch from Steve Marshall, modified by me.

replace the old recursive-SQL-function implementation of _pg_keysequal()
with use of the built-in array containment operators, and change
table_constraints' UNION to UNION ALL.  Per discussion with Octavio Alvarez.

initdb not forced since this doesn't affect results, but you'd need to
initdb or reload the information_schema to see the new definitions.

any LISTEN command.  This is more important than it used to be because
DISCARD ALL invokes UNLISTEN.  Connection-pooled applications making heavy
use of DISCARD ALL were seeing significant contention for pg_listener,
as reported by Matteo Beccati.  It seems unlikely that clients using LISTEN
would use pooled connections, so this simple tweak seems sufficient,
especially since the pg_listener implementation is slated to go away soon
anyway.

Back-patch to 8.3, where DISCARD ALL was introduced.

instead of vice versa.  Update the regression test expectations to support
that.  In the plpgsql test, adjust the test data so that this isn't an
issue.  In the char and varchar tests, add new expected files.

speak in tongues and mess up the regression test diffs.

as this seems to crash on at least some versions of MingW. Our current usage
of this function does not require it, so it should be ok to ignore.

get rid of the OID column.  This eliminates the problem discovered by Heikki
back in November that 8.4's suppression of "unnecessary" junk filtering in
INSERT/SELECT could lead to an Assert failure, or storing of oids into a table
that shouldn't have them if Asserts are off.  While that particular problem
could have been solved in other ways, it seems likely to be just a forerunner
of things to come if we continue to allow tables to contain rows that disagree
with the pg_class.relhasoids setting.  It's better to make this operation slow
than to sacrifice performance or risk bugs in more common code paths.

Also, add ALTER TABLE SET WITH OIDS to rewrite the table to add oids.
This was a bit more controversial, but in view of the very small amount of
extra code needed given the current ALTER TABLE infrastructure, it seems best
to eliminate the asymmetry in features.

on AIX with a non-gcc compiler.  The previous coding would do this only if
CC was exactly "xlc"; which is a bad idea, as demonstrated by trouble report
from Mihai Criveti.

ITAGAKI Takahiro.

presumably designed, but didn't act).  This allows running the temp install
tests in a non-C locale, thus exercising users' real environments better.
Document how to change locales for test runs.

make maintenance harder.

arguments.

collection.

contents of hash indexes (again), so bump catversion.

Kenneth Marshall

per-table overrides of parameters.

This removes a whole class of problems related to misusing the catalog,
and perhaps more importantly, gives us pg_dump support for the parameters.

Based on a patch by Euler Taveira de Oliveira, heavily reworked by me.

Erik Rijkers

from the source table.  This could never happen anyway before 8.4 because
the executor invariably applied a "junk filter" to rows due to be inserted;
but now that we skip doing that when it's not necessary, the case can occur.
Problem noted 2008-11-27 by KaiGai Kohei, though I misunderstood what he
was on about at the time (the opacity of the patch he proposed didn't help).

btree;  keep mention about missing WAL logging.

Kenneth Marshall