On Sun, Dec 11, 2016 at 9:06 AM, Andrew Dunstan <and...@dunslane.net> 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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to