On Sun, Dec 11, 2016 at 9:06 AM, Andrew Dunstan <[email protected]> wrote:
>
> jascana (mingw, 64 bit compiler, no openssl) is currently hung on "make
> check". After starting the autovacuum launcher there are 120 messages on its
> log about "Could not acquire random number". Then nothing.
>
>
> So I suspect the problem here is commit
> fe0a0b5993dfe24e4b3bcf52fa64ff41a444b8f1, although I haven't looked in
> detail.
>
>
> Shouldn't we want the postmaster to shut down if it's not going to go
> further? Note that frogmouth, also mingw, which builds with openssl, doesn't
> have this issue.
Did you unlock it in some way at the end? Here is the shape of the
report for others:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2016-12-10%2022%3A00%3A15
And here is of course the interesting bit:
2016-12-10 17:25:38.822 EST [584c80e2.ddc:2] LOG: could not acquire
random number
2016-12-10 17:25:39.869 EST [584c80e2.ddc:3] LOG: could not acquire
random number
2016-12-10 17:25:40.916 EST [584c80e2.ddc:4] LOG: could not acquire
random number
I am not seeing any problems with MSVC without openssl, so that's a
problem proper to MinGW. I am getting to wonder if it is actually a
good idea to cache the crypt context and then re-use it. Using a new
context all the time is definitely not performance-wise though. A
second difference are the missing CRYPT_MACHINE_KEYSET and
CRYP_NEWKEYSET. So, with something like the patch attached, do you see
improvements? What this patch does is to use a different context at
each call, and with the key container flags to allow proper access to
it (as there are winxp-only limitations here). I have tried to compile
with MinGW in my environment but my gcc compiler keep crashing, so I
cannot reproduce directly the problem I am afraid.
--
Michael
diff --git a/src/port/pg_strong_random.c b/src/port/pg_strong_random.c
index 6d3aa38..34cab6f 100644
--- a/src/port/pg_strong_random.c
+++ b/src/port/pg_strong_random.c
@@ -31,14 +31,6 @@
#include <Wincrypt.h>
#endif
-#ifdef WIN32
-/*
- * Cache a global crypto provider that only gets freed when the process
- * exits, in case we need random numbers more than once.
- */
-static HCRYPTPROV hProvider = 0;
-#endif
-
#if defined(USE_DEV_URANDOM)
/*
* Read (random) bytes from a file.
@@ -111,28 +103,36 @@ pg_strong_random(void *buf, size_t len)
* Windows has CryptoAPI for strong cryptographic numbers.
*/
#elif defined(USE_WIN32_RANDOM)
- if (hProvider == 0)
+ HCRYPTPROV hProvider;
+ DWORD flags;
+
+ flags = CRYPT_VERIFYCONTEXT | CRYPT_SILENT | CRYPT_MACHINE_KEYSET;
+
+ /* Create a crypto provider */
+ if (!CryptAcquireContext(&hProvider,
+ NULL,
+ MS_DEF_PROV,
+ PROV_RSA_FULL,
+ flags))
{
+ /* If previous creation failed, try with a new key container */
+ flags |= CRYPT_NEWKEYSET;
if (!CryptAcquireContext(&hProvider,
NULL,
MS_DEF_PROV,
PROV_RSA_FULL,
- CRYPT_VERIFYCONTEXT | CRYPT_SILENT))
- {
- /*
- * On failure, set back to 0 in case the value was for some reason
- * modified.
- */
- hProvider = 0;
- }
+ flags))
+ return false;
}
- /* Re-check in case we just retrieved the provider */
- if (hProvider != 0)
+
+ if (!CryptGenRandom(hProvider, len, buf))
{
- if (CryptGenRandom(hProvider, len, buf))
- return true;
+ CryptReleaseContext(hProvider, 0);
+ return false;
}
- return false;
+
+ CryptReleaseContext(hProvider, 0);
+ return true;
/*
* Read /dev/urandom ourselves.
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
