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

From Thomas Munro
Subject Re: DSM segment handle generation in background workers
Date
Msg-id CAEepm=1xxETRCZexNSxkABpNg-65U6Z2pxynJ8V0vURqob+Rqw@mail.gmail.com
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  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: executor relation handling
Next
From: Michael Paquier
Date:
Subject: Re: Restore CurrentUserId only if 'prevUser' is valid when aborttransaction