On Thu, Oct 11, 2018 at 5:51 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > The comment adjacent to the change in InitStandaloneProcess bothers me. > In particular, it points out that what BackendRun() is currently doing > creates more entropy in the process's random seed than what you have > here: MyStartTime is only good to the nearest second, whereas the code > you removed from BackendRun() factors in fractional seconds to whatever > the precision of GetCurrentTimestamp is. This does not seem like an > improvement.
True. > I'm inclined to think we should refactor a bit more aggressively so > that, rather than dumbing backends down to the standard of other > processes, we make them all use the better method. A reasonable way > to approach this would be to invent a global variable MyStartTimestamp > beside MyStartTime, and initialize both of them in the places that > currently initialize the latter, using code like that in > BackendInitialize: > > /* save process start time */ > port->SessionStartTime = GetCurrentTimestamp(); > MyStartTime = timestamptz_to_time_t(port->SessionStartTime); > > and then this new InitRandomSeeds function could adopt BackendRun's > seed initialization method instead of the stupider way. Ok, done. With MyStartTimestamp in the picture, port->SessionStartTime is probably redundant... <looks around> and in fact the comment in struct Port says it shouldn't even be there. So... I removed it, and used the new MyStartTimestamp in the couple of places that wanted it. Thoughts? > Possibly it'd be sane to merge the MyStartTime* initializations > and the srandom resets into one function, not sure. +1 The main difficulty was coming up with a name for the function that does those things. I went with InitProcessGlobals(). Better suggestions welcome. -- Thomas Munro http://www.enterprisedb.com
0001-Refactor-random-seed-and-start-time-initialization.patch
Description: Binary data
