From: | Marko Kreen <markokr(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgcrypto seeding problem when ssl=on |
Date: | 2013-01-14 12:21:00 |
Message-ID: | CACMqXCK=+UrWBZ4uJ8gymnaggGzRvwxww3anAZw2OLYPJ1SK8Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 14, 2013 at 12:46 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marko Kreen <markokr(at)gmail(dot)com> writes:
>> On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>>> How about instead calling RAND_cleanup() after each backend fork?
>
>> Attached is a patch that adds RAND_cleanup() to fork_process().
>
> I remain unconvinced that this is the best solution. Anybody else have
> an opinion?
Do you have knowledge about systems that have /dev/random (blocking)
but not /dev/urandom (non-blocking)? The only argument I see against
RAND_cleanup() is that postgres might eat entropy from /dev/random (blocking)
and cause both other programs and itself block, waiting for more entropy.
But this can only happen on systems that don't have /dev/urandom.
Note: reading from /dev/urandom does not affect /dev/random.
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2013-01-14 13:00:42 | Re: pgcrypto seeding problem when ssl=on |
Previous Message | Andres Freund | 2013-01-14 12:04:00 | Re: passing diff options to pg_regress |