happened to be right up against the end of memory, per report from
Matt Magoffin.  While at it, avoid useless multiple copying of string
by not depending on xmlStrncatNew.

release notes.

Adjust contrib/tsearch2 regression results to use XML tag and XML entity descriptions, as now used by core text search default parser.

Re-order some items as migration changes.

Allow tag and entity names that follow XML rules. Provide for hexadecimal
as well as decimal numeric entities. Adjust code names to coincide with
new descriptions.

< 	o Prevent COMMENT ON dbname from issuing a warning when loading
< 	  into a database with a different name, perhaps using COMMENT ON
< 	  CURRENT DATABASE
> 	o Change pg_dump so that a comment on the dumped database is
> 	  applied to the loaded database, even if the database has a
> 	  different name.  This will require new backend syntax, perhaps
> 	  COMMENT ON CURRENT DATABASE.

< 	o Allow COMMENT ON dbname to work when loading into a database
< 	  with a different name, perhaps using COMMENT ON CURRENT
<           DATABASE
> 	o Prevent COMMENT ON dbname from issuing a warning when loading
> 	  into a database with a different name, perhaps using COMMENT ON
> 	  CURRENT DATABASE

< 	  with a different name
> 	  with a different name, perhaps using COMMENT ON CURRENT
>           DATABASE
>

databases.

> 	o Allow COMMENT ON dbname to work when loading into a database
> 	  with a different name

A bunch of other desultory copy-editing, too.

ambiguity and say what the default value is.

plans.

item to #1 imcompatibility slot.

GetMemoryChunkSpace, not just the palloc request size.  This brings the
allocatedMemory counter close enough to reality (as measured by
MemoryContextStats printouts) that I think we can get rid of the arbitrary
factor-of-2 adjustment that was put into the code initially.  Given the
sensitivity of GIN build to work memory size, not using as much of work
memory as we're allowed to seems a pretty bad idea.

Else, in a 64-bit machine with maintenance_work_mem set to above 4Gb,
the counter overflows and we never recognize having reached the
maintenance_work_mem limit.  I believe this explains out-of-memory
failure recently reported by Sean Davis.

This is a bug, so backpatch to 8.2.

it failed for splits of non-leaf pages because in such pages the first
data key on a page is suppressed, and so we can't just copy the first
key from the right page to reconstitute the left page's high key.
Problem found by Koichi Suzuki, patch by Heikki.

alias.

Patch by Bruce Momjian <bruce@momjian.us>

Backpatch is needed, but it's impossible to apply it directly

update files for beta3

sensitive to maintenance_work_mem (something I just learned the hard
way).