On 28/12/2018 01:14, Tom Lane wrote:
Michael Paquier <mich...@paquier.xyz> writes:
On Thu, Dec 27, 2018 at 03:56:52PM -0500, Tom Lane wrote:
More urgently, what about the lack of --disable-strong-random
coverage? I feel like we should either have a buildfarm
critter or two testing that code, or decide that it's no longer
interesting and rip it out. backend_random.c, to name just
one place, has a complex enough !HAVE_STRONG_RANDOM code path
that I don't feel comfortable letting it go totally untested.
If that proves to not be useful, just dropping the switch sounds like
a good option to me. I would be curious to hear Heikki on the matter
as he has introduced the switch in the v10 time-frame.
I might be misremembering, but I think it was me that pressed to have
that switch in the first place :-). The reason my feelings have changed
on the matter is mainly that we recently moved the compiler goalposts
to C99. That reduces to about nil the chances of people being able to
build PG on pre-turn-of-the-century platforms, at least without a lot
of add-on software. So the idea that we should be able to cope with
platforms lacking /dev/urandom has correspondingly dropped in value.
Judging by our buildfarm sample, nothing released in this century
lacks /dev/urandom.
Yeah, there probably isn't anyone needing --disable-strong-random in
practice. The situation is slightly different between the frontend and
backend, though. It's more likely that someone might need to build libpq
on a very ancient system, but not the server. And libpq only needs
pg_strong_random() for SCRAM support. It'd be kind of nice to still be
able to build libpq without pg_strong_random(), with SCRAM disabled. But
that's awkward to arrange with autoconf, there is no "--libpq-only"
flag. Perhaps replace the backend !HAVE_STRONG_RANDOM code with #error.
+1 for just ripping it out, nevertheless. If someone needs libpq on an
ancient system, they can build an older version of libpq as a last resort.
- Heikki
