Repo copy files

Stamp release 7.3.21.

Security: CVE-2007-4769, CVE-2007-4772, CVE-2007-6067, CVE-2007-6600, CVE-2007-6601

Update release notes for security releases.

Security: CVE-2007-4769, CVE-2007-4772, CVE-2007-6067, CVE-2007-6600, CVE-2007-6601

The original patch to disallow non-passworded connections to non-superusers
failed to cover all the ways in which a connection can be initiated in dblink.
Plug the remaining holes.  Also, disallow transient connections in functions
for which that feature makes no sense (because they are only sensible as
part of a sequence of operations on the same connection).  Joe Conway

Security: CVE-2007-6601

Make standard maintenance operations (including VACUUM, ANALYZE, REINDEX,
and CLUSTER) execute as the table owner rather than the calling user, using
the same privilege-switching mechanism already used for SECURITY DEFINER
functions.  The purpose of this change is to ensure that user-defined
functions used in index definitions cannot acquire the privileges of a
superuser account that is performing routine maintenance.  While a function
used in an index is supposed to be IMMUTABLE and thus not able to do anything
very interesting, there are several easy ways around that restriction; and
even if we could plug them all, there would remain a risk of reading sensitive
information and broadcasting it through a covert channel such as CPU usage.

To prevent bypassing this security measure, execution of SET SESSION
AUTHORIZATION and SET ROLE is now forbidden within a SECURITY DEFINER context.

Thanks to Itagaki Takahiro for reporting this vulnerability.

Security: CVE-2007-6600

Provide a more helpful error message when there is an autoconf version
mismatch;  backpatch.

Require a specific Autoconf version, instead of a lower bound only.

Fix "Page Layout" table. The second row should be ItemIdData, not
ItemPointerData.

Have crosstab variants treat NULL rowid as a category in its own right,
per suggestion from Tom Lane. This fixes crash-bug reported by Stefan
Schwarzer.

Ensure that the result of evaluating a function during constant-expression
simplification gets detoasted before it is incorporated into a Const node.
Otherwise, if an immutable function were to return a TOAST pointer (an
unlikely case, but it can be made to happen), we would end up with a plan
that depends on the continued existence of the out-of-line toast datum.

Fix bogus calculation of potential output string length in translate().

Update release notes for last-minute fix.

Fix aboriginal mistake in lazy VACUUM's code for truncating away
no-longer-needed pages at the end of a table.  We thought we could throw away
pages containing HEAPTUPLE_DEAD tuples; but this is not so, because such
tuples very likely have index entries pointing at them, and we wouldn't have
removed the index entries.  The problem only emerges in a somewhat unlikely
race condition: the dead tuples have to have been inserted by a transaction
that later aborted, and this has to have happened between VACUUM's initial
scan of the page and then rechecking it for empty in count_nondeletable_pages.
But that timespan will include an index-cleaning pass, so it's not all that
hard to hit.  This seems to explain a couple of previously unsolved bug
reports.

tag configure for 7.3.20

Fix markup that doesn't work in back branches.

Minor editorialization on release notes.

Translation updates

Stamp releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20.

Update FAQs for 8.2.5.

Stamp

Fix aboriginal bug in _tarAddFile(): when complaining that the amount of data
read from the temp file didn't match the file length reported by ftello(),
the wrong variable's value was printed, and so the message made no sense.
Clean up a couple other coding infelicities while at it.

Fix combo_decrypt() to throw an error for zero-length input when using a
padded encryption scheme.  Formerly it would try to access res[(unsigned) -1],
which resulted in core dumps on 64-bit machines, and was certainly trouble
waiting to happen on 32-bit machines (though in at least the known case
it was harmless because that byte would be overwritten after return).
Per report from Ken Colson; fix by Marko Kreen.

Fix potential access-off-the-end-of-memory in varbit_out(): it fetched the
byte after the last full byte of the bit array, regardless of whether that
byte was part of the valid data or not.  Found by buildfarm testing.
Thanks to Stefan Kaltenbrunner for nailing down the cause.

Fix pg_restore to guard against unexpected EOF while reading an archive file.
Per report and partial patch from Chad Wagner.

Fix elog.c to avoid infinite recursion (leading to backend crash) when
log_min_error_statement is active and there is some problem in logging the
current query string; for example, that it's too long to include in the log
message without running out of memory.  This problem has existed since the
log_min_error_statement feature was introduced.  No doubt the reason it
wasn't detected long ago is that 8.2 is the first release that defaults
log_min_error_statement to less than PANIC level.
Per report from Bill Moran.

Make replace(), split_part(), and string_to_array() behave somewhat sanely
when handed an invalidly-encoded pattern.  The previous coding could get
into an infinite loop if pg_mb2wchar_with_len() returned a zero-length
string after we'd tested for nonempty pattern; which is exactly what it
will do if the string consists only of an incomplete multibyte character.
This led to either an out-of-memory error or a backend crash depending
on platform.  Per report from Wiktor Wodecki.

Fix outfuncs.c to dump A_Const nodes representing NULLs correctly.  This has
been broken since forever, but was not noticed because people seldom look
at raw parse trees.  AFAIK, no impact on users except that debug_print_parse
might fail; but patch it all the way back anyway.  Per report from Jeff Ross.

Restrict non-superusers to password authenticated connections
to prevent possible escalation of privilege. Provide new SECURITY
DEFINER functions with old behavior, but initially REVOKE ALL
from public for these functions. Per list discussion and design
proposed by Tom Lane.

Fix failure to restart Postgres when Linux kernel returns EIDRM for shmctl().

This is a Linux kernel bug that apparently exists in every extant kernel
version: sometimes shmctl() will fail with EIDRM when EINVAL is correct.
We were assuming that EIDRM indicates a possible conflict with pre-existing
backends, and refusing to start the postmaster when this happens.  Fortunately,
there does not seem to be any case where Linux can legitimately return EIDRM
(it doesn't track shmem segments in a way that would allow that), so we can
get away with just assuming that EIDRM means EINVAL on this platform.

Per reports from Michael Fuhr and Jon Lapham --- it's a bit surprising
we have not seen more reports, actually.

Fix a passel of ancient bugs in to_char(), including two distinct buffer
overruns (neither of which seem likely to be exploitable as security holes,
fortunately, since the provoker can't control the data written).  One of
these is due to choosing to stomp on the output of a called function, which
is bad news in any case; make it treat the called functions' results as
read-only.  Avoid some unnecessary palloc/pfree traffic too; it's not
really helpful to free small temporary objects, and again this is presuming
more than it ought to about the nature of the results of called functions.
Per report from Patrick Welche and additional code-reading by Imad.

transformColumnDefinition failed to complain about
create table foo (bar int default null default 3);
due to not thinking about the special-case handling of DEFAULT NULL.
Problem noticed while investigating bug #3396.

CREATE DOMAIN ... DEFAULT NULL failed because gram.y special-cases DEFAULT
NULL and DefineDomain didn't.  Bug goes all the way back to original coding
of domains.  Per bug #3396 from Sergey Burladyan.

Fix aboriginal bug in BufFileDumpBuffer that would cause it to write the
wrong data when dumping a bufferload that crosses a component-file boundary.
This probably has not been seen in the wild because (a) component files are
normally 1GB apiece and (b) non-block-aligned buffer usage is relatively
rare.  But it's fairly easy to reproduce a problem if one reduces RELSEG_SIZE
in a test build.  Kudos to Kurt Harriman for spotting the bug.

Fix dynahash.c to suppress hash bucket splits while a hash_seq_search() scan
is in progress on the same hashtable.  This seems the least invasive way to
fix the recently-recognized problem that a split could cause the scan to
visit entries twice or (with much lower probability) miss them entirely.
The only field-reported problem caused by this is the "failed to re-find
shared lock object" PANIC in COMMIT PREPARED reported by Michel Dorochevsky,
which was caused by multiply visited entries.  However, it seems certain
that mdsync() is vulnerable to missing required fsync's due to missed
entries, and I am fearful that RelationCacheInitializePhase2() might be at
risk as well.  Because of that and the generalized hazard presented by this
bug, back-patch all the supported branches.

Along the way, fix pg_prepared_statement() and pg_cursor() to not assume
that the hashtables they are examining will stay static between calls.
This is risky regardless of the newly noted dynahash problem, because
hash_seq_search() has never promised to cope with deletion of table entries
other than the just-returned one.  There may be no bug here because the only
supported way to call these functions is via ExecMakeTableFunctionResult()
which will cycle them to completion before doing anything very interesting,
but it seems best to get rid of the assumption.  This affects 8.2 and HEAD
only, since those functions weren't there earlier.

Fix newly-introduced documentation typo.

Update configure.in for release

Security: hold for release

Fix markup.

Security: CVE-2007-2138

Fix markup.

Security: CVE-2007-2138

Support explicit placement of the temporary-table schema within search_path.
This is needed to allow a security-definer function to set a truly secure
value of search_path.  Without it, a malicious user can use temporary objects
to execute code with the privileges of the security-definer function.  Even
pushing the temp schema to the back of the search path is not quite good
enough, because a function or operator at the back of the path might still
capture control from one nearer the front due to having a more exact datatype
match.  Hence, disable searching the temp schema altogether for functions and
operators.

Security: CVE-2007-2138

Release wording updates for releases 8.2.4, 8.1.9, 8.0.13, 7.4.17, 7.3.19.

Update FAQ to mention most recent release for releases
8.2.4, 8.1.9, 8.0.13, 7.4.17, 7.3.19.

Update FAQ to mention most recent release for releases
8.2.4, 8.1.9, 8.0.13, 7.4.17, 7.3.19.

Stamp releases 8.2.4, 8.1.9, 8.0.13, 7.4.17, 7.3.19.

Release note updates for 8.2.4, 8.1.9, 8.0.13, 7.4.17, 7.3.19.

Fix pg_wchar_table's maxmblen field of EUC_CN, EUC_TW, MULE_INTERNAL
and GB18030. patches from ITAGAKI Takahiro.

Fix a longstanding bug in VACUUM FULL's handling of update chains.  The code
did not expect that a DEAD tuple could follow a RECENTLY_DEAD tuple in an
update chain, but because the OldestXmin rule for determining deadness is a
simplification of reality, it is possible for this situation to occur
(implying that the RECENTLY_DEAD tuple is in fact dead to all observers,
but this patch does not attempt to exploit that).  The code would follow a
chain forward all the way, but then stop before a DEAD tuple when backing
up, meaning that not all of the chain got moved.  This could lead to copying
the chain multiple times (resulting in duplicate copies of the live tuple at
its end), or leaving dangling index entries behind (which, aside from
generating warnings from later vacuums, creates a risk of wrong query
results or bogus duplicate-key errors once the heap slot the index entry
points to is repopulated).

The fix is to recheck HeapTupleSatisfiesVacuum while following a chain
forward, and to stop if a DEAD tuple is reached.  Each contiguous group
of RECENTLY_DEAD tuples will therefore be copied as a separate chain.
The patch also adds a couple of extra sanity checks to verify correct
behavior.

Per report and test case from Pavan Deolasee.

Fix markQueryForLocking() to work correctly in the presence of nested views.
It has been wrong for this case since it was first written for 7.1 :-(
Per report from Pavel Hanák.

Update 7.x variant horology files to match the new US DST rules.  It seems
likely that anyone wanting to run the regression tests in the future will
have up-to-date system timezone files, so this is more likely to work than
the old contents.

Fix an ancient logic error in plpgsql's exec_stmt_block: it thought it could
get away with not (re)initializing a local variable if the variable is marked
"isconst" and not "isnull".  Unfortunately it makes this decision after having
already freed the old value, meaning that something like

   for i in 1..10 loop
     declare c constant text := 'hi there';

leads to subsequent accesses to freed memory, and hence probably crashes.
(In particular, this is why Asif Ali Rehman's bug leads to crash and not
just an unexpectedly-NULL value for SQLERRM: SQLERRM is marked CONSTANT
and so triggers this error.)

The whole thing seems wrong on its face anyway: CONSTANT means that you can't
change the variable inside the block, not that the initializer expression is
guaranteed not to change value across successive block entries.  Hence,
remove the "optimization" instead of trying to fix it.

Rearrange use of plpgsql_add_initdatums() so that only the parsing of a
DECLARE section needs to know about it.  Formerly, everyplace besides DECLARE
that created variables needed to do "plpgsql_add_initdatums(NULL)" to prevent
those variables from being sucked up as part of a subsequent DECLARE block.
This is obviously error-prone, and in fact the SQLSTATE/SQLERRM patch had
failed to do it for those two variables, leading to the bug recently exhibited
by Asif Ali Rehman: a DECLARE within an exception handler tried to reinitialize
SQLERRM.

Although the SQLSTATE/SQLERRM patch isn't in any pre-8.1 branches, and so
I can't point to a demonstrable failure there, it seems wise to back-patch
this into the older branches anyway, just to keep the logic similar to HEAD.

Stamp release 7.3.18.

Security: CVE-2007-0555, CVE-2007-0556

Update release notes for security-related releases in all active branches.

Security: CVE-2007-0555, CVE-2007-0556

Repair insufficiently careful type checking for SQL-language functions:
we should check that the function code returns the claimed result datatype
every time we parse the function for execution.  Formerly, for simple
scalar result types we assumed the creation-time check was sufficient, but
this fails if the function selects from a table that's been redefined since
then, and even more obviously fails if check_function_bodies had been OFF.

This is a significant security hole: not only can one trivially crash the
backend, but with appropriate misuse of pass-by-reference datatypes it is
possible to read out arbitrary locations in the server process's memory,
which could allow retrieving database content the user should not be able
to see.  Our thanks to Jeff Trout for the initial report.

Security: CVE-2007-0555

Translation updates

Correct an old logic error in btree page splitting: when considering a split
exactly at the point where we need to insert a new item, the calculation used
the wrong size for the "high key" of the new left page.  This could lead to
choosing an unworkable split, resulting in "PANIC: failed to add item to the
left sibling" (or "right sibling") failure.  Although this bug has been there
a long time, it's very difficult to trigger a failure before 8.2, since there
was generally a lot of free space on both sides of a chosen split.  In 8.2,
where the user-selected fill factor determines how much free space the code
tries to leave, an unworkable split is much more likely.  Report by Joe
Conway, diagnosis and fix by Heikki Linnakangas.

Get pg_utf_mblen(), pg_utf2wchar_with_len(), and utf2ucs() all on the same
page about the maximum UTF8 sequence length we support (4 bytes since 8.1,
3 before that).  pg_utf2wchar_with_len never got updated to support 4-byte
characters at all, and in any case had a buffer-overrun risk in that it
could produce multiple pg_wchars from what mblen claims to be just one UTF8
character.  The only reason we don't have a major security hole is that most
callers allocate worst-case output buffers; the sole exception in released
versions appears to be pre-8.2 iwchareq() (ie, ILIKE), which can be crashed
due to zeroing out its return address --- but AFAICS that can't be exploited
for anything more than a crash, due to inability to control what gets written
there.  Per report from James Russell and Michael Fuhr.

Pre-8.1 the risk is much less, but I still think pg_utf2wchar_with_len's
behavior given an incomplete final character risks buffer overrun, so
back-patch that logic change anyway.

This patch also makes sure that UTF8 sequences exceeding the supported
length (whichever it is) are consistently treated as error cases, rather
than being treated like a valid shorter sequence in some places.

Back port patch.

Call srandom() instead of srand().
pgbench calls random() later, so it should have called srandom().
On most platforms except Windows srandom() is actually identical
to srand(), so the bug only bites Windows users.
per bug report from Akio Ishida.

Fix markup because older releases couldn't like to refernce pages.

Fix markup because lc_numeric didn't have an SGML tag in this release.

tag for 7.3.17 ...

Minor copy-editing for release note updates.

Stamp release 7.3.17.

Create release notes for 7.3.17.

Fix regex_fixed_prefix() to cope reasonably well with regex patterns of the
form '^(foo)$'.  Before, these could never be optimized into indexscans.
The recent changes to make psql and pg_dump generate such patterns (for \d
commands and -t and related switches, respectively) therefore represented
a big performance hit for people with large pg_class catalogs, as seen in
recent gripe from Erik Jones.  While at it, be more paranoid about
case-sensitivity checking in multibyte encodings, and fix some other
corner cases in which a regex might be interpreted too liberally.

Repair bug #2839: the various ExecReScan functions need to reset
ps_TupFromTlist in plan nodes that make use of it.  This was being done
correctly in join nodes and Result nodes but not in any relation-scan nodes.
Bug would lead to bogus results if a set-returning function appeared in the
targetlist of a subquery that could be rescanned after partial execution,
for example a subquery within EXISTS().  Bug has been around forever :-(
... surprising it wasn't reported before.

Mark to_number() and the numeric-type variants of to_char() as stable, not
immutable, because their results depend on lc_numeric; this is a longstanding
oversight.  We cannot force initdb for this in the back branches, but we can
at least provide correct catalog entries for future installations.

Fix 1-byte buffer overrun when OID exceeds 1 billion.  This probably can't
cause any serious harm in normal cases, but if you have gcc buffer overrun
checking turned on, that will notice.  Found by Jack Orenstein.  Problem
was already fixed in CVS HEAD.

Stamp 7.3.16.

A bit of copy-editing on back-branch release notes.

Fix psql \d commands to behave properly when a pattern using regex | is given.
Formerly they'd emit '^foo|bar$' which is wrong because the anchors are
parsed as part of the alternatives; must emit '^(foo|bar)$' to get expected
behavior.  Same as bug found previously in similar_escape().  Already fixed
in HEAD, this is just back-porting the part of that patch that was a bug fix.

Update libpq.rc for 7.3.16 and 7.4.14.  Later releases use libpq.rc.in,
which was already updated.

Stamp releases 7.3.16, 7.4.14, 8.0.9, and 8.1.5.

Update release notes for releases 7.3.16, 7.4.14, 8.0.9, and 8.1.5.

Fix back-branch pg_regress scripts to try the "canonical" expected file if we
tried a variant file from resultmap and it didn't match.  This is already done
in HEAD's C-code version, and is needed because OpenBSD has recently migrated
to a more standard handling of float underflow --- see buildfarm results
from emu.

Fix ancient oversight in psql's \d pattern processing code: when seeing two
quote chars inside quote marks, should emit one quote *and stay in inquotes
mode*.  No doubt the lack of reports of this have something to do with the
poor documentation of the feature ...

Clean up rather sloppy fix in HEAD for the ancient bug that CREATE CONVERSION
didn't create a dependency from the new conversion to its schema.  Back-patch
to all supported releases.

Fix bug introduced by last patch, thanks again to Mario Weilguni <[email protected]>

fix bug about modifying value in shared buffer,
what was a reason to corrupt index.
Thank to Mario Weilguni <[email protected]> to
discover a bug.

A recent backpatch to 7.3's contrib/ltree got mixed up, putting code in
the wrong place.  This moves it to the right place which allows it to
compile. Patch from Kris Jurka.

Fix bug corrupting query in gist consistent function.
Thank to Mario Weilguni <[email protected]> to discover a bug.

Fix dbmirror for new backslash escaping:

Martin Pitt [2006-06-16  0:15 +0200]:
> Upstream confirmed my reply in the last mail in [1]: the complete
> escaping logic in DBMirror.pl is seriously screwew.
>
> [1] http://archives.postgresql.org/pgsql-bugs/2006-06/msg00065.php

I finally found some time to debug this, and I think I found a better
patch than the one you proposed. Mine is still hackish and is still a
workaround around a proper quoting solution, but at least it repairs
the parsing without introducing the \' quoting again.

I consider this a band-aid patch to fix the recent security update.
PostgreSQL gurus, would you consider applying this until a better
solution is found for DBMirror.pl?

Martin Pitt        http://www.piware.de

Back-patch 7.4-era fix for memory leak with SSL connections due to
missing X509_free() calls.  Per a request from a Red Hat customer;
seems silly for Red Hat to be shipping a patch that's not in upstream.

Back-port Postgres 7.4 spinlock code into 7.3 branch.  This adds
previously-missing spinlock code for x86_64 and ppc64 architectures,
converts the ppc/ppc64 code into gcc inlines, and provides a better
spinlock backoff algorithm on all architectures.  Aside from being
almost identical to the community 7.4 source code, this exact patch
has been in use for awhile in Red Hat's RHEL3 RPMs, so I have pretty
good confidence in it.  Why bother, you ask?  I'm taking pity on a
couple of buildfarm members that have been vainly trying to build 7.3
on these 64-bit architectures.

Pre-8.0 branches need to cope with possibility that the system libc knows
about the recent changes in US DST law.  Add a variant horology file, so
that either the old or new rules will be considered valid test results.

Stamp release 7.3.15.

Update release notes for upcoming releases.

Stamp releases 7.3.15, 7.4.13, and 8.0.8.

Modify libpq's string-escaping routines to be aware of encoding considerations
and standard_conforming_strings.  The encoding changes are needed for proper
escaping in multibyte encodings, as per the SQL-injection vulnerabilities
noted in CVE-2006-2313 and CVE-2006-2314.  Concurrent fixes are being applied
to the server to ensure that it rejects queries that may have been corrupted
by attempted SQL injection, but this merely guarantees that unpatched clients
will fail rather than allow injection.  An actual fix requires changing the
client-side code.  While at it we have also fixed these routines to understand
about standard_conforming_strings, so that the upcoming changeover to SQL-spec
string syntax can be somewhat transparent to client code.

Since the existing API of PQescapeString and PQescapeBytea provides no way to
inform them which settings are in use, these functions are now deprecated in
favor of new functions PQescapeStringConn and PQescapeByteaConn.  The new
functions take the PGconn to which the string will be sent as an additional
parameter, and look inside the connection structure to determine what to do.
So as to provide some functionality for clients using the old functions,
libpq stores the latest encoding and standard_conforming_strings values
received from the backend in static variables, and the old functions consult
these variables.  This will work reliably in clients using only one Postgres
connection at a time, or even multiple connections if they all use the same
encoding and string syntax settings; which should cover many practical
scenarios.

Clients that use homebrew escaping methods, such as PHP's addslashes()
function or even hardwired regexp substitution, will require extra effort
to fix :-(.  It is strongly recommended that such code be replaced by use of
PQescapeStringConn/PQescapeByteaConn if at all feasible.

Add a new GUC parameter backslash_quote, which determines whether the SQL
parser will allow "\'" to be used to represent a literal quote mark.  The
"\'" representation has been deprecated for some time in favor of the
SQL-standard representation "''" (two single quote marks), but it has been
used often enough that just disallowing it immediately won't do.  Hence
backslash_quote allows the settings "on", "off", and "safe_encoding",
the last meaning to allow "\'" only if client_encoding is a valid server
encoding.  That is now the default, and the reason is that in encodings
such as SJIS that allow 0x5c (ASCII backslash) to be the last byte of a
multibyte character, accepting "\'" allows SQL-injection attacks as per
CVE-2006-2314 (further details will be published after release).  The
"on" setting is available for backward compatibility, but it must not be
used with clients that are exposed to untrusted input.

Thanks to Akio Ishida and Yasuo Ohgaki for identifying this security issue.

Change the backend to reject strings containing invalidly-encoded multibyte
characters in all cases.  Formerly we mostly just threw warnings for invalid
input, and failed to detect it at all if no encoding conversion was required.
The tighter check is needed to defend against SQL-injection attacks as per
CVE-2006-2313 (further details will be published after release).  Embedded
zero (null) bytes will be rejected as well.  The checks are applied during
input to the backend (receipt from client or COPY IN), so it no longer seems
necessary to check in textin() and related routines; any string arriving at
those functions will already have been validated.  Conversion failure
reporting (for characters with no equivalent in the destination encoding)
has been cleaned up and made consistent while at it.

Also, fix a few longstanding errors in little-used encoding conversion
routines: win1251_to_iso, win866_to_iso, euc_tw_to_big5, euc_tw_to_mic,
mic_to_euc_tw were all broken to varying extents.

Patches by Tatsuo Ishii and Tom Lane.  Thanks to Akio Ishida and Yasuo Ohgaki
for identifying the security issues.

Change \' to '', for SQL standards compliance.  Backpatch to 7.3, 7.4,
and 8.0.  Later releases already patched.

Fix the sense of the test on DH_check()'s return value.  This was preventing
custom-generated DH parameters from actually being used by the server.
Found by Michael Fuhr.

Remove unnecessary .seg/.section directives, per Alan Stange.

Fix ancient memory leak in PQprintTuples(); our code no longer uses this
routine, but perhaps some applications do.  Found by Martijn van Oosterhout
using Coverity.

Minor teak.

Tighten up SJIS byte sequence check. Now we reject invalid SJIS byte
sequence such as "0x95 0x27". Patches from Akio Ishida.

Fix three Python reference leaks in PLy_traceback(). This would result
in leaking memory when invoking a PL/Python procedure that raises an
exception. Unfortunately this still leaks memory, but at least the
largest leak has been plugged.

This patch also fixes a reference counting mistake in PLy_modify_tuple()
for 8.0, 8.1 and HEAD: we don't actually own a reference to `platt', so
we shouldn't Py_DECREF() it.

Patch from Marko Kreen:

pgcrypto crypt()/md5 and hmac() leak memory when compiled against
OpenSSL as openssl.c digest ->reset will do two DigestInit calls
against a context.  This happened to work with OpenSSL 0.9.6
but not with 0.9.7+.

Reason for the messy code was that I tried to avoid creating
wrapper structure to transport algorithm info and tried to use
OpenSSL context for it.  The fix is to create wrapper structure.

It also uses newer digest API to avoid memory allocations
on reset with newer OpenSSLs.

Thanks to Daniel Blaisdell for reporting it.

Stamp 7.3.14.

Update release notes.

Fix bug in SET SESSION AUTHORIZATION that allows unprivileged users to crash
the server, if it has been compiled with Asserts enabled (CVE-2006-0553).
Thanks to Akio Ishida for reporting this problem.