Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnA3T-0001q3-4G for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Sep 2016 19:53:11 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bnA3R-0002bX-Vp for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Sep 2016 19:53:10 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bnA23-00089v-Lq for pgsql-hackers@postgresql.org; Thu, 22 Sep 2016 19:51:43 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bnA21-0000w0-C3 for pgsql-hackers@postgresql.org; Thu, 22 Sep 2016 19:51:42 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u8MJpaAh011823; Thu, 22 Sep 2016 15:51:36 -0400 From: Tom Lane To: Robert Haas cc: Amit Kapila , Dmitry Vasilyev , pgsql-hackers Subject: Re: =?UTF-8?Q?Re=3A_=5BHACKERS=5D_Re=3A_=5BHACKERS=5D_Re=3A_=5BHACKERS=5D_Windows_se?= =?UTF-8?Q?rvice_is_not_starting_so_there=E2=80=99s_message_in_log=3A_FATAL=3A_=22c?= =?UTF-8?Q?ould_not_create_shared_memory_segment_=E2=80=9CGlobal=2FPostgreSQL=2E8?= =?UTF-8?Q?51401618=E2=80=9D=3A_Permission_denied=E2=80=9D?= In-reply-to: References: <1444920387.3661.7.camel@postgrespro.ru> <1444921511.3661.13.camel@postgrespro.ru> <20789.1474390434@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Tue, 20 Sep 2016 13:05:03 -0400" Date: Thu, 22 Sep 2016 15:51:36 -0400 Message-ID: <11822.1474573896@sss.pgh.pa.us> X-Pg-Spam-Score: -5.0 (-----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Robert Haas writes: > On Tue, Sep 20, 2016 at 12:53 PM, Tom Lane 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers