delta/postgresql.git, branch REL8_3_14

Tag 8.3.14

2011-01-28T02:24:47+00:00

Update release notes.

2011-01-27T22:47:27+00:00

Security: CVE-2010-4015

Prevent buffer overrun while parsing an integer in a "query_int" value.

2011-01-27T22:43:34+00:00

contrib/intarray's gettoken() uses a fixed-size buffer to collect an
integer's digits, and did not guard against overrunning the buffer.
This is at least a backend crash risk, and in principle might allow
arbitrary code execution.  The code didn't check for overflow of the
integer value either, which while not presenting a crash risk was still
bad.

Thanks to Apple Inc's security team for reporting this issue and supplying
the fix.

Security: CVE-2010-4015

Don't include unnecessarily.

2011-01-27T21:29:59+00:00

We only need that header when compiling with icc, since the gcc variant of
ia64_get_bsp() uses in-line assembly code.  Per report from Frank Brendel,
the header doesn't exist on all IA64 platforms; so don't include it unless
we need it.

Translation updates for release 8.3.14

2011-01-27T21:13:12+00:00

Update release notes for releases 9.0.3, 8.4.7, 8.3.14, and 8.2.20.

2011-01-27T21:10:08+00:00

Fix pg_restore to do the right thing when escaping large objects.

2011-01-21T21:22:27+00:00

Specifically, this makes the workflow pg_dump -Fc -> pg_restore -> file
produce correct output for BLOBs when the source database has
standard_conforming_strings turned on.  It was already okay when that was
off, or if pg_restore was told to restore directly into a database.

This is a back-port of commit b1732111f233bbb72788e92a627242ec28a85631 of
2009-08-04, with additional changes to emit old-style escaped bytea data
instead of hex-style.  At the time, we had not heard of anyone encountering
the problem in the field, so I judged it not worth the risk of changing
back branches.  Now we do have a report, from Bosco Rama, so back-patch
into 8.2 through 8.4.  9.0 and up are okay already.

Fix miscalculation of itemsafter in array_set_slice().

2011-01-17T17:40:51+00:00

If the slice to be assigned to was before the existing array lower bound
(requiring at least one null element to spring into existence to fill the
gap), the code miscalculated how many entries needed to be copied from
the old array's null bitmap.  This could result in trashing the array's
data area (as seen in bug #5840 from Karsten Loesing), or worse.

This has been broken since we first allowed the behavior of assigning to
non-adjacent slices, in 8.2.  Back-patch to all affected versions.

Revert installation of gram.h in 8.3

2011-01-11T10:31:42+00:00

To make the buildfarm green again, since there is no file to
copy on msvc, and also given discussion about the necessity
of the file at all...

Ensure the directory for gram.h is created on win32

2011-01-09T16:04:09+00:00

Result of bad testing of my last commit.