Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gcbqv-0005xY-MU for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Dec 2018 20:01:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gcbpv-0008V8-Ii for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Dec 2018 20:00:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gcbpv-0008R4-7U for pgsql-hackers@lists.postgresql.org; Thu, 27 Dec 2018 20:00:55 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gcbps-0005fC-5B for pgsql-hackers@postgresql.org; Thu, 27 Dec 2018 20:00:53 +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 wBRK0anL010519; Thu, 27 Dec 2018 15:00:36 -0500 From: Tom Lane To: Peter Geoghegan cc: Michael Paquier , Alvaro Herrera , Adrien Nayrat , Thomas Munro , Dmitry Dolgov <9erthalion6@gmail.com>, Tomas Vondra , Vik Fearing , Robert Haas , David Rowley , Pg Hackers Subject: Re: random() (was Re: New GUC to sample log queries) In-reply-to: <9585.1545939214@sss.pgh.pa.us> References: <20181129214850.kiq6mvofsgplqjdr@alvherre.pgsql> <3859.1545849900@sss.pgh.pa.us> <20181227013458.GF2106@paquier.xyz> <32696.1545875185@sss.pgh.pa.us> <2820.1545878340@sss.pgh.pa.us> <9585.1545939214@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 27 Dec 2018 14:33:34 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10517.1545940836.1@sss.pgh.pa.us> Date: Thu, 27 Dec 2018 15:00:36 -0500 Message-ID: <10518.1545940836@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I wrote: > Peter Geoghegan writes: >> We're already making fairly broad assumptions about our having control >> of the backend's PRNG state within InitProcessGlobals(). How should >> this affect the new drandom()/setseed() private state, if at all? > I would think that InitProcessGlobals would initialize drandom's > seed alongside random()'s seed. Hopefully to values not easily > predictable from each other -- see also Munro's comment, which > I'll respond to in a moment. On further reflection, it seems likely that in most installations a lot of processes never invoke drandom()/setseed() at all, making such work in InitProcessGlobals a waste of cycles. Probably a better idea is to have drandom() initialize the seed on first use, if it wasn't already set by setseed(). This might also make it easier to decouple that seed value from the random() sequence --- we could use a fresh timestamp value, and perhaps another strong-RNG call, though I'm not sure if the latter is worthwhile. regards, tom lane