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).

compatibility module.  Needed to support loading of 8.1-era tsearch2
configuration data.

for() body passed as a parameter, make the macros act as simple headers
to code blocks.

This allows pgindent to be run on these files.

same line;  previous fix was only partial.  Re-run pgindent on files
that need it.

avoid this problem in the future.)

appear in the configuration file.

support the latter.

checkpoint.  This guards against an unlikely data-loss scenario in which
we re-use the relfilenode, then crash, then replay the deletion and
recreation of the file.  Even then we'd be OK if all insertions into the
new relation had been WAL-logged ... but that's not guaranteed given all
the no-WAL-logging optimizations that have recently been added.

Patch by Heikki Linnakangas, per a discussion last month.