Re: DSM segment handle generation in background workers - Mailing list pgsql-hackers

From Tom Lane
Subject Re: DSM segment handle generation in background workers
Date
Msg-id 9879.1539233472@sss.pgh.pa.us
Whole thread Raw
In response to Re: DSM segment handle generation in background workers  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: DSM segment handle generation in background workers  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
Thomas Munro <thomas.munro@enterprisedb.com> writes:
>> Ok, here is a sketch patch with a new function InitRandomSeeds() to do
>> that.  It is called from PostmasterMain(), InitPostmasterChild() and
>> InitStandaloneProcess() for consistency.

> Here's a version I propose to push to master and 11 tomorrow, if there
> are no objections.

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.

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.

Possibly it'd be sane to merge the MyStartTime* initializations
and the srandom resets into one function, not sure.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Calculate total_table_pages after set_base_rel_sizes()
Next
From: aviral1701
Date:
Subject: Mentorship