result now depends on the lc_messages setting, as noted by Bruce.
Also, mark to_number() and the numeric-type variants of to_char() as stable,
because their results depend on lc_numeric; this is a longstanding oversight.
Also, mark to_date() and to_char(interval) as stable; although these appear
not to depend on any GUC variables as of CVS HEAD, that seems a property
unlikely to survive future improvements.  It seems best to mark all the
formatting functions stable and be done with it.
catversion not bumped, because this does not seem critical enough to force
a post-RC1 initdb, and anyway we cannot do so in the back branches.

protect vfprintf from hijacking by Windows gettext just like other members of the *printf family.

update for rc1

vacuum/analyze timestamp columns at the end, rather than at a random
spot in the middle as in the original patch.  This was deemed more usable
as well as less likely to break existing application code.  initdb forced
accordingly.  In passing, remove former kluge for initializing
pg_stat_file()'s pg_proc entry --- bootstrap mode was fixed recently
so that this can be done without any hacks, but I overlooked this usage.

Walter Cruz

some of the Windows-only makefiles; the correct place to assert these
things is pg_config.h.win32.  Per bug #2677.

cases where we already hold the desired lock "indirectly", either via
membership in a MultiXact or because the lock was originally taken by a
different subtransaction of the current transaction.  These cases must be
accounted for to avoid needless deadlocks and/or inappropriate replacement of
an exclusive lock with a shared lock.  Per report from Clarence Gardner and
subsequent investigation.

more space is needed, instead of incrementing by a fixed amount; the old
method wastes lots of space and time when the ultimate size is large.
Per gripe from Tatsuo.

Tag as Beta3 ... two outstanding *known* bugs before RC1 ...

include it if it links properly.  It seems too risky to assume that
standard functions like pow() are not special-cased by the compiler.
Per report from Andreas Lange that build fails on Solaris cc compiler
with -fast.  Even though we don't consider that a supported option,
I'm worried that similar issues will arise with other compilers.

stale relcache init files (pg_internal.init), and there is no mechanism for
updating them during WAL replay.  Easiest solution is just to delete the init
files at conclusion of startup, and let the first backend started in each
database take care of rebuilding the init file.  Simon Riggs and Tom Lane.

Back-patched to 8.1.  Arguably this should be fixed in 8.0 too, but it would
require significantly more code since 8.0 has no handy startup-time scan of
pg_database to piggyback on.  Manual solution of the problem is possible
in 8.0 (just delete the pg_internal.init files before starting WAL replay),
so that may be a sufficient answer.

in PITR scenarios.  We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases.  Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId.  Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done.  Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database.  initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs.  Heikki Linnakangas, Simon Riggs, and Tom Lane.

deletion code to avoid the case where an upper-level btree page remains "half
dead" for a significant period of time, and to block insertions into a key
range that is in process of being re-assigned to the right sibling of the
deleted page's parent.  This prevents the scenario reported by Ed L. wherein
index keys could become out-of-order in the grandparent index level.

Since this is a moderately invasive fix, I'm applying it only to HEAD.
The bug exists back to 7.4, but the back branches will get a different patch.

provide a macro so code can still just say qsort).  Avoids linker warnings
on pickier platforms such as Darwin, and outright failure on MSVC.

from Magnus that MSVC complains about this.

timezone actually has a daylight-savings rule.  This avoids breaking
cases that used to work because they went through the DecodePosixTimezone
code path.  Per contrib regression failures (mea culpa for not running
those yesterday...).  Also document the already-applied change to allow
GMT offsets up to 14 hours.

modules; the first try was not usable in EXEC_BACKEND builds (e.g.,
Windows).  Instead, just provide some entry points to increase the
allocation requests during postmaster start, and provide a dedicated
LWLock that can be used to synchronize allocation operations performed
by backends.  Per discussion with Marc Munro.

don't cheat on the raw-vs-cooked status of a constraint.

max_stack_depth is not set to an unsafe value.

This commit also provides configure-time checking for <sys/resource.h>,
and cleans up some perhaps-unportable code associated with use of that
include file and getrlimit().

been initialized yet.  This can happen because there are code paths that call
SysCacheGetAttr() on a tuple originally fetched from a different syscache
(hopefully on the same catalog) than the one specified in the call.  It
doesn't seem useful or robust to try to prevent that from happening, so just
improve the function to cope instead.  Per bug#2678 from Jeff Trout.  The
specific example shown by Jeff is new in 8.1, but to be on the safe side
I'm backpatching 8.0 as well.  We could patch 7.x similarly but I think
that's probably overkill, given the lack of evidence of old bugs of this ilk.

remaining functions, simplify pglz_compress's API to not require a useless
data copy when compression fails.  Also add a check in pglz_decompress that
the expected amount of data was decompressed.

static variables.  This avoids any risk of potential non-reentrancy,
and in particular offers a much cleaner workaround for the Intel compiler
bug that was affecting ginutil.c.

proposed patches from John Jorgensen and Steve Singer.

Buildfarm results from 'gazelle' show that there are indeed libedit
versions for which history.h is a needed header, even though it's
apparently been dropped entirely in other versions.  Grumble.

Per Bob Friesenhahn's report, this file is not supplied by some versions
of libedit, and even when it is supplied it seems to be just a link to
readline.h, so we don't need to include it anyway.
Also, ensure that we won't try to use a too-old version of Bison.
The previous coding would bleat but then use it anyway; better to invoke
the 'missing' script if any grammar files need to be rebuilt.

repeatedly.  Now that we don't have to worry about memory leaks from
glibc's qsort, we can safely put CHECK_FOR_INTERRUPTS into the tuplesort
comparators, as was requested a couple months ago.  Also, get rid of
non-reentrancy and an extra level of function call in tuplesort.c by
providing a variant qsort_arg() API that passes an extra void * argument
through to the comparison routine.  (We might want to use that in other
places too, I didn't look yet.)

postgresql.conf.

- shared_buffers = 32000kB => 32MB
- temp_buffers = 8000kB => 8MB
- wal_buffers = 8 => 64kB

The code of initdb was a bit modified to write MB-unit values.
Values greater than 8000kB are rounded out to MB.

GUC_UNIT_XBLOCKS is added for wal_buffers. It is like GUC_UNIT_BLOCKS,
but uses XLOG_BLCKSZ instead of BLCKSZ.

Also, I cleaned up the test of GUC_UNIT_* flags in preparation to
add more unit flags in less bits.

ITAGAKI Takahiro

defined too late.

declared in the system headers.  Per report from Bruce than some BSDen
are like this.

work around that with defines.

the SQL spec, viz IS NULL is true if all the row's fields are null, IS NOT
NULL is true if all the row's fields are not null.  The former coding got
this right for a limited number of cases with IS NULL (ie, those where it
could disassemble a ROW constructor at parse time), but was entirely wrong
for IS NOT NULL.  Per report from Teodor.

I desisted from changing the behavior for arrays, since on closer inspection
it's not clear that there's any support for that in the SQL spec.  This
probably needs more consideration.