| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Christoph Moench-Tegeder <cmt(at)burggraben(dot)net> |
| Cc: | Michael Mühlbeyer <Michael(dot)Muehlbeyer(at)trivadis(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: md5 issues Postgres14 on OL7 |
| Date: | 2022-01-04 11:52:56 |
| Message-ID: | YdQ1GLqQ/Vq6LwW9@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Dec 20, 2021 at 03:22:31PM +0100, Christoph Moench-Tegeder wrote:
> Active FIPS mode (/proc/sys/crypto/fips_enabled => 1) on the server does
> produce this behaviour.
Most likely, this is a build linked with OpenSSL? The way MD5 hashes
are computed in Postgres has largely changed in 14, and the code has
been refactored so as we rely on the EVP APIs from OpenSSL when
building with --with-ssl=openssl, having as direct consequence to
allocate a bit more memory every time a hash is computed. My guess is
that this comes from pg_cryptohash_create() in cryptohash_openssl.c,
with a complain coming from OpenSSL's EVP_MD_CTX_create(), but there
are other palloc() calls in this area as well.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-01-04 15:01:56 | Re: restoring a single database from a pg_dumpall dump file |
| Previous Message | Matthias Apitz | 2022-01-04 08:30:01 | restoring a single database from a pg_dumpall dump file |