Re: DSM segment handle generation in background workers

Thomas Munro <thomas.munro@enterprisedb.com>

From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-10-11T03:18:40Z
Lists: pgsql-hackers

Attachments

On Tue, Oct 9, 2018 at 3:21 PM Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Tue, Oct 9, 2018 at 1:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Thomas Munro <thomas.munro@enterprisedb.com> writes:
> > > On Mon, Oct 8, 2018 at 1:17 AM Thomas Munro
> > > <thomas.munro@enterprisedb.com> wrote:
> > >> That's because the bgworker startup path doesn't contain a call to
> > >> srandom(...distinguishing stuff...), unlike BackendRun().  I suppose
> > >> do_start_bgworker() could gain a similar call... or perhaps that call
> > >> should be moved into InitPostmasterChild().  If we put it in there
> > >> right after MyStartTime is assigned a new value, we could use the same
> > >> incantation that PostmasterMain() uses.
> >
> > > Maybe something like this?
> >
> > I think the bit with
> >
> > #ifndef HAVE_STRONG_RANDOM
> >         random_seed = 0;
> >         random_start_time.tv_usec = 0;
> > #endif
> >
> > should also be done in every postmaster child, no?  If we want to hide the
> > postmaster's state from child processes, we ought to hide it from all.
>
> 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.

-- 
Thomas Munro
http://www.enterprisedb.com

Commits

  1. Increase the number of possible random seeds per time period.

  2. Refactor pid, random seed and start time initialization.

  3. Increase the number of different values used when seeding random().