On Fri, Sep 23, 2016 at 1:21 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Sep 20, 2016 at 12:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I'd be the first to agree that this point is inadequately documented >>> in the code, but PostmasterRandom should be reserved for its existing >>> security-related uses, not exposed to the world for (ahem) random other >>> uses. > >> So, we could have dsm_postmaster_startup() seed the random number >> generator itself, and then let PostmasterRandom() override the seed >> later. Like maybe: > > Works for me, at least as a temporary solution. The disturbing thing > here is that this still only does what we want if dsm_postmaster_startup > happens before the first PostmasterRandom call --- which is OK today but > seems pretty fragile. Still, redesigning PostmasterRandom's seeding > technique is not something to do right before 9.6 release. Let's revert > the prior patch and do it as you have here: > >> struct timeval tv; >> gettimeofday(&tv, NULL); >> srandom(tv.tv_sec); >> ... >> dsm_control_handle = random(); > > for the time being. >
Isn't it better if we use the same technique in dsm_create() as well which uses random() for handle? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers