exceed the total number of non-dropped source table fields for
dblink_build_sql_*(). Addresses bug report from Rushabh Lathia.
Backpatch all the way to the 7.3 branch.
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
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.
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.
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.
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
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.
0.9.7x have EVP_DigestFinal function which which clears all of
EVP_MD_CTX. This makes pgcrypto crash in functions which
re-use one digest context several times: hmac() and crypt()
with md5 algorithm.
Following patch fixes it by carring the digest info around
EVP_DigestFinal and re-initializing cipher.
Marko Kreen.
with ReturnSetInfo->expectedDesc. This allows custom datatypes
(e.g. from tsearch2) to be returned at runtime. Previous behavior
depended on the type oid to match between the remote and local
database, which obviously doesn't work well for custom types.
Per report from Mark Gibson.
ltree_73.patch.gz - for 7.3 :
Fix ~ operation bug: eg '1.1.1' ~ '*.1'
ltree_74.patch.gz - for current CVS
Fix ~ operation bug: eg '1.1.1' ~ '*.1'
Add ? operation
Optimize index storage
Last change needs drop/create all ltree indexes, so only for 7.4
Teodor Sigaev
bison 1.875 and later as we did from earlier bison releases. Eventually
we will probably want to adopt the newer message spelling ... but not yet.
Per recent discussion on pgpatches.
Note: I didn't change the build rules for bootstrap, ecpg, or plpgsql
grammars, since these do not affect regression test results.
exists if and only if locale of postmaster
was a different from C (or ru_RU.KOI8-R).
Please, apply patch for current CVS & 7.3.1
Magnus Naeslund(f) wrote:
> Ok, I nailed the bug, but i'm not sure what the correct fix is.
> Attached tsearch_morph.diff that remedies this problem by avoiding it.
> Also there's a debug aid patch if someone would like to know how i
> finally found it out :)
>
> There problem in the lemmatize() function is that GETDICT(...) returned
> a value not handled (BYLOCALE).
> The value (-1) and later used as an index into the dicts[] array.
> After that everything went berserk stack went crazy somehow so trapping
> the fault sent me to the wrong place, and every time i read the value it
> was positive ;)
>
> So now i just return the initial word passed to the lemmatize function,
> because i don't know what to do with it.
Magnus Naeslund
