On 12/12/2016 05:58 AM, Michael Paquier wrote:
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.
Actually, looking at the config.log on jacana, it's trying to use
/dev/urandom:
configure:15028: checking for /dev/urandom
configure:15041: result: yes
configure:15054: checking which random number source to use
configure:15073: result: /dev/urandom
And looking closer at configure.in, I can see why:
elif test "$PORTNAME" = x"win32" ; then
USE_WIN32_RANDOM=1
That test is broken. It looks like the x"$VAR" = x"constant" idiom, but
the left side of the comparison doesn't have the 'x'. Oops.
Fixed that, let's see if it made jacana happy again.
This makes me wonder if we should work a bit harder to get a good error
message, if acquiring a random number fails for any reason. This needs
to work in the frontend as well backend, but we could still have an
elog(LOG, ...) there, inside an #ifndef FRONTEND block.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
